220 30780 <63e10ea7-0878-cc71-743f-745d21dd93c8@wanadoo.fr> article Path: news.gmane.org!.POSTED!not-for-mail From: "Vicente J. Botet Escriba" Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Make Typedef Great Again Date: Sun, 5 Feb 2017 15:17:48 +0100 Lines: 646 Approved: news@gmane.org Message-ID: <63e10ea7-0878-cc71-743f-745d21dd93c8@wanadoo.fr> References: Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------------CEC1AE1C0732D1A7041EAEB5" X-Trace: blaine.gmane.org 1486304269 25586 195.159.176.226 (5 Feb 2017 14:17:49 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 5 Feb 2017 14:17:49 +0000 (UTC) User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDH67CONY4PBBDPI3TCAKGQE3GAQBHI@isocpp.org Sun Feb 05 15:17:45 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-lf0-f70.google.com ([209.85.215.70]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1caNdR-0006TU-5n for gclcip-std-proposals@m.gmane.org; Sun, 05 Feb 2017 15:17:45 +0100 Original-Received: by mail-lf0-f70.google.com with SMTP id o12sf25174834lfg.7 for ; Sun, 05 Feb 2017 06:17:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:x-original-sender:x-original-authentication-results :reply-to:precedence:mailing-list:list-id:x-spam-checked-in-group :list-post:list-help:list-archive:list-subscribe:list-unsubscribe; bh=av4wRLpWXJpenvRKDDuYvFM3x0cYWI9TSTqTcT9nYpc=; b=OhOMaIpafdGIzUy0MC2nFuM5xQHjnpTDSbOXNWUWUyi2kTYdk6tPvu9CGgXfxdSHxY OUK2EUPb6oIYXQ1lfmN+scb6VXTAJ1HMRegVZa2UJdqctjkz8F2QSnJr6MPxSPL9cPmq DAYXNJCSfrfys+IoR5ZljhDNXUA2PN3XDYy4a061b/V1e4WcsOe8HeY+rnqmwnfJt8Me ko7w3IxXnFryvyYt1IMoYTPyxkbJ81iLVo3GyPL/fSDuVsDWYBQndfiGbn4wUEMoE87m 52MFSivZgWaK7Pv9Mr1bpqRjGymMom1fuYFJvp05YFz2tIFBSFBCDVqzKsVkDb6UFM0K /uTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=av4wRLpWXJpenvRKDDuYvFM3x0cYWI9TSTqTcT9nYpc=; b=jLdXs5qfJ1F8bTEvDtDPdInVlIw2IbaiqytGKbtozH3a5KVo3IgzEzkULfcU9ssj4b +NRMaqHoE3jf2sTHIP7tNDNIQuVP/PKdU5unIhUlVxMFuR5V+1J7Z+zZmglBSnpxqBNT LU3k18HjizW9M/EoEs/C/KU+fPiFh3BnhzYIyZtVpAi6q6SAElGSsuXc0jX4ue2NHbCf b4VY8+89LhKpbJzjRTHAbPl+060sx2TLP/LaurBlKAFrHVEMQRQxcpXHcAZVv07PlAra 5Ci3nAH+L+9fxfdckPgApyOWMOg4kobnoDZvWwOSpbQUdMkjN0J62JwnFIbBwnVqmnR2 PReg== X-Gm-Message-State: AIkVDXLdq8OvJ6PAfHYrQEGLGDOgll/yS4CpTNXfn5oLo5BMIO+bdOfjp3EAkQ3nH0hIrA== X-Received: by 10.46.21.13 with SMTP id s13mr622244ljd.23.1486304270908; Sun, 05 Feb 2017 06:17:50 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.28.6.146 with SMTP id 140ls782572wmg.26.canary-gmail; Sun, 05 Feb 2017 06:17:49 -0800 (PST) X-Received: by 10.223.135.146 with SMTP id b18mr5389479wrb.189.1486304269731; Sun, 05 Feb 2017 06:17:49 -0800 (PST) Original-Received: from smtp.smtpout.orange.fr (smtp13.smtpout.orange.fr. [80.12.242.135]) by mx.google.com with ESMTPS id w94si32837142wrc.107.2017.02.05.06.17.49 for (version=TLS1 cipher=AES128-SHA bits=128/128); Sun, 05 Feb 2017 06:17:49 -0800 (PST) Received-SPF: neutral (google.com: 80.12.242.135 is neither permitted nor denied by best guess record for domain of vicente.botet@wanadoo.fr) client-ip=80.12.242.135; Original-Received: from imac-de-vicente-botet-escriba.home ([2.11.72.89]) by mwinf5d75 with ME id h2Ho1u00H1vahZu032Hofy; Sun, 05 Feb 2017 15:17:49 +0100 X-ME-Helo: imac-de-vicente-botet-escriba.home X-ME-Auth: dmljZW50ZS5ib3RldEB3YW5hZG9vLmZy X-ME-Date: Sun, 05 Feb 2017 15:17:49 +0100 X-ME-IP: 2.11.72.89 In-Reply-To: X-Original-Sender: vicente.botet@wanadoo.fr X-Original-Authentication-Results: mx.google.com; spf=neutral (google.com: 80.12.242.135 is neither permitted nor denied by best guess record for domain of vicente.botet@wanadoo.fr) smtp.mailfrom=vicente.botet@wanadoo.fr Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:30780 Archived-At: This is a multi-part message in MIME format. --------------CEC1AE1C0732D1A7041EAEB5 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Le 05/02/2017 =C3=A0 13:56, TONGARI J a =C3=A9crit : > On Sunday, February 5, 2017 at 6:41:36 PM UTC+8, Vicente J. Botet=20 > Escriba wrote: > > I'm not saying the feature is not needed. I believe however that > the proposal needs to compare what it is currently doable. > > Couldn't we use the existing language already > > | > template |typenameMetaFunc::type |> > T f()// yay! > { > // Use `T` from now on... > } > | > > In this case, it's just an alternative w/o (ab)using the template=20 > param, like how concept-lite tries to eliminate enable_if trick. Maybe. I'd prefer to have the possibility to use the result type as e.g.=20 decltype(return). > > | > template Base=3D|typenameMetaFunc::type|> > classDerived:publicBase// yay! > { > // Use `Base` from now on... > } > | > > This does not work if "blahblah...", is actually a template parameter=20 > pack, which has to be the last one. Right. This are the kind of cases you mush show on your proposal, the=20 cases that cannot be solved with the current languages. >> In parameter list: >> | >> template >> voidf(typedefSomeTemplateT a,T b);// yay! >> | >> > I'm not sure the |blahblahcould be inferred > > Do tou mean > > | > |template > voidf(U, typedefSomeTemplateT a,T b); > | > > > I mean something like: > | > template > voidf(typedefstd::tupleT a,T b); > > f(std::make_tuple(1,2),std::make_tuple(3,4));//Args =3D=3D {int, int}, T= =20 > =3D=3D std::tuple > | |template voidf(std::tuplea,decltype(a) b) { using T =3D decltype(a); // make use of T } I believe I have an idea that could be less cryptic and reuse the=20 current alias. What about defining some alias at the same level as the requires clasue? | | template *|requires using T =3D |**|typenameMetaFunc::type // let T =3D= |* T f()// yay! { // Use `T` from now on... } | | template *requires using **|Base=3D|typenameMetaFunc::type ||*|*|// let Base =3D|*| classDerived:publicBase// yay! { // Use `Base` from now on... } | ||template ||*|||requires| ||**|||using T| =3D ||*||||*std**::**tuple**<**Args**...>* ||voidf(T a,T b); Vicente || --=20 You received this message because you are subscribed to the Google Groups "= ISO C++ Standard - Future Proposals" group. To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposals+unsubscribe@isocpp.org. To post to this group, send email to std-proposals@isocpp.org. To view this discussion on the web visit https://groups.google.com/a/isocpp= ..org/d/msgid/std-proposals/63e10ea7-0878-cc71-743f-745d21dd93c8%40wanadoo.f= r. --------------CEC1AE1C0732D1A7041EAEB5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Le 05/02/2017 =C3=A0 13:56, TONGARI J a =C3=A9crit=C2=A0:
On Sunday, February 5, 2017 at 6:41:36 PM UTC+8, Vicente J. Botet Escriba wrote:=C2=A0
I'm not saying the feature is not needed. I believe however that the proposal needs to compare what it is currently doable.

Couldn't we use the existing language already

template<blahblah..., typename T =3D <= /span>typename MetaFunc<blahblah...>::type >=
T f() // yay!
{
=C2=A0 =C2=A0 // Use = `T` from now on...
}
In this case, it's just an alternative w/o (ab)using the template param, like how concept-lite tries to eliminate enable_if trick.
Maybe. I'd prefer to have the possibility to use the result type as e.g. decltype(return).
=C2=A0
template<blahblah..., typename Base=3D<= /span>typename MetaFunc<blahblah...>::type><= span style=3D"color:#000">
class Derived : public Base // yay!
{
=C2=A0 =C2=A0 // Use = `Base` from now on...
}
=C2=A0
This does not work if "blahblah...", is actually a template parameter pack, which has to be the last one.
Right. This are the kind of cases you mush show on your proposal, the cases that cannot be solved with the current languages.

In parameter list:
template<blahblah...>
void f(typedef SomeTemplate<blahblah...> T a, T b); // yay!

I'm not sure the blahblah could be inferred

Do tou mean


template<class U>=
void f(U= , typedef Som= eTemplate<= U> T a, T b= );

I mean something like:
template<class... Args>
void f(typedef= std::tuple<Args...>= T a, T b);

f(std::make_= tuple(1, 2), std::make_tu= ple(3, 4)); //Args =3D=3D {int, int}, T =3D=3D std::tuple<int, int>
template<class... Args>
void= f(std::tuple<Args...><= span style=3D"color: #000;" class=3D"styled-by-prettify"> a, decltype(a) b<= /span>) {
=C2=A0=C2=A0=C2=A0 using T =3D decltype(a);
=C2=A0=C2=A0=C2=A0 // make use of T
}

I believe I have an idea that could be less cryptic and reuse the current alias.
What about defining some alias at the same level as the requires clasue?
template<= blahblah...>
requires using T =3D <= /span>typename MetaFun= c<blahbla= h...>= ::type // let T =3D
= T f() // yay!
= {
=C2=A0 =C2=A0 // Use `T` from now on...
= }


template<= blahblah...&= gt;
requires using Base=3D<= /span>typename MetaFunc<blahblah...>::type /= / let Base =3D
class Derived : public Base // yay!
{
=C2=A0 =C2=A0 // Use `Bas= e` from now on...
}


template<= class...<= span style=3D"color: #000;" class=3D"styled-by-prettify"> Args= >
requires = using=C2=A0 T =3D s= td:= :t= uple&= lt;A= rgs= ....>
void= f(T a<= span style=3D"color: #660;" class=3D"styled-by-prettify">, T b= );

Vicente

--
You received this message because you are subscribed to the Google Groups &= quot;ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposa= ls+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.= com/a/isocpp.org/d/msgid/std-proposals/63e10ea7-0878-cc71-743f-745d21dd93c8= %40wanadoo.fr.
--------------CEC1AE1C0732D1A7041EAEB5-- .