220 30783 article Path: news.gmane.org!.POSTED!not-for-mail From: TONGARI J Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Make Typedef Great Again Date: Sun, 5 Feb 2017 17:48:15 -0800 (PST) Lines: 367 Approved: news@gmane.org Message-ID: References: <63e10ea7-0878-cc71-743f-745d21dd93c8@wanadoo.fr> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_5100_1198539314.1486345695550" X-Trace: blaine.gmane.org 1486345697 5657 195.159.176.226 (6 Feb 2017 01:48:17 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 6 Feb 2017 01:48:17 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCC3NA775MLBBYFL37CAKGQET3MXHTQ@isocpp.org Mon Feb 06 02:48:13 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-it0-f72.google.com ([209.85.214.72]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1caYPc-0001FA-N9 for gclcip-std-proposals@m.gmane.org; Mon, 06 Feb 2017 02:48:13 +0100 Original-Received: by mail-it0-f72.google.com with SMTP id 203sf69336833ith.3 for ; Sun, 05 Feb 2017 17:48:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=88AdHeepPw0ndG6Ddqh26jLdpGqS0khNz3G0bLK70CA=; b=iIEIRRFVidoC3kLRMvPXQBT/AXH65KJkt2OCO+HBZ5Q/oS2FjWAoWgsQzclvbEBrHi y3I6JekJuCcEGtlVtI8DkjhpwMfsbwWVi/+ZnUZgf7fs1latodsQrElu6JZNU6D60705 TrFqVkhq3b0dhEj8wlIlV/GWqkCpATcMoK7AWus3U+IPKWMbX9BNBnR2FTEfkMXklcM0 5kb/WT4rVfNGkJwf9B07Sul581sPoITWUAlHQvN6J735rrprIrF5ptTRk/colnjOuF4M b+yZdISAKVPIrSzAj5OE7jQyLK1HzVmCyKsHiUoWoD5Ke9m0bDuw5plpn+EyEziQCXwe vlhA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=88AdHeepPw0ndG6Ddqh26jLdpGqS0khNz3G0bLK70CA=; b=LPAMIMiZHRVdbH2/TSTsFpPkhDY4b30zuSy9oJBuuU9fDAGVMCUenj3LO5NDr8hUnm /AKKhkGl3ji6k7k7Fk/KSXCpE9WXHoXwiqeMwEUB+oKWS8vfRlUxTq1LM6Va7ORDe5D1 UCgw2zZdRYqioH7hiyUtaQIJnavZddMlc5EAsu4z90FZlDsqlAjO3Qu9yrH71gxBcT+l tei6UY4btc4jeNAc7zzaFZeATd/ARGkZpo9+HBzfCMWaLPW7yDPARssbrYXbnZm+auKc tO+NruMxd3mD5jashFBihE1Bj3p8Vpe7UOhbtRf6XMHfZertGGq778zoeKx5wBEWOZAR rnUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:message-id:in-reply-to:references :subject:mime-version:x-original-sender:reply-to:precedence :mailing-list:list-id:x-spam-checked-in-group:list-post:list-help :list-archive:list-subscribe:list-unsubscribe; bh=88AdHeepPw0ndG6Ddqh26jLdpGqS0khNz3G0bLK70CA=; b=BhWXT8whRlgd0gy0ri0a43fy2qrSJzAqKDvKClAbGZvlzNnXZfkRhIZi9JB5j+Avt3 vmGPN3kvpXLuaY8NE+weYxqGwouDkYyNK2hzHyj1suXsT2Moj0AOyKVAVZ68LvZjbrKC 3YEHAEQ+V7VLNjZye0HEnlqnRoG1UDDHVeoSmIBxbJrWIIVgGg9Z7REA2FE3gG9gD4Jh oWul5HyLhTBsyrIXF50/UouhC7HDXS7TrkWJQ135I/HacTo7kMcKTJ9dJn7IK5mtKENv 5cyUYUB9FYKQg1DsoIV8mj9/5aUSPbkRgQimVd40KfnXxAYY0pvzhZPODa+j8sEx5Hce 79fA== X-Gm-Message-State: AMke39l9U/TkJkpQbJvipVgy+2zLt5FE5uZ+weG4tIy3woBnziUqHYVLqM9T8vms0Oybxg== X-Received: by 10.107.140.22 with SMTP id o22mr1775728iod.54.1486345697798; Sun, 05 Feb 2017 17:48:17 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.157.1.212 with SMTP id e78ls11457714ote.9.gmail; Sun, 05 Feb 2017 17:48:16 -0800 (PST) X-Received: by 10.157.43.215 with SMTP id u81mr378711ota.15.1486345696258; Sun, 05 Feb 2017 17:48:16 -0800 (PST) In-Reply-To: <63e10ea7-0878-cc71-743f-745d21dd93c8@wanadoo.fr> X-Original-Sender: tongari95@gmail.com 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:30783 Archived-At: ------=_Part_5100_1198539314.1486345695550 Content-Type: multipart/alternative; boundary="----=_Part_5101_1188588797.1486345695551" ------=_Part_5101_1188588797.1486345695551 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sunday, February 5, 2017 at 10:17:51 PM UTC+8, Vicente J. Botet Escriba= =20 wrote: > > 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 Escriba= =20 > wrote: =20 >> >> I'm not saying the feature is not needed. I believe however that the=20 >> proposal needs to compare what it is currently doable. >> >> Couldn't we use the existing language already >> >> template::typ= e > >> T f() // yay! >> { >> // Use `T` from now on... >> } >> >> In this case, it's just an alternative w/o (ab)using the template param,= =20 > 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). > I have no problem with decltype(return), but it's a specific solution to a= =20 single case. If we could have a general solution to all similar cases, I'd= =20 pursue it. > =20 > >> template::ty= pe> >> class Derived : public Base // yay! >> { >> // Use `Base` from now on... >> } >> > =20 > 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. > > I mean something like: > template > void f(typedef std::tuple T 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 > void f(std::tuple a, decltype(a) b) { > using T =3D decltype(a); > // make use of T > } > Even though using decltype may make it shorter, it's still not ideal,=20 suppose you now have more than 2 params not just a & b. =20 > I believe I have an idea that could be less cryptic and reuse the current= =20 > alias.=20 > What about defining some alias at the same level as the requires clasue? > The crux of the extended typedef is that it allows you to declare both a=20 type and variables at once. The idea of such a composite declaration is not novel, as in C++ we already= =20 have: struct S{} s; // Declares type 'S' and varaible 's' So I think C++ programmers should be familiar with such a style, and=20 extended typedef is just a natural extension of this style. The simple type deduction is also an important feature of extended typedef: typedef auto T& ref =3D getSomeRef(...);=20 otherwise, we have to do more verbose auto& ref =3D getSomeRef(...); using T =3D std::remove_reference_t; > --=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/e2d22969-1510-448f-acfd-44e421fc300b%40isocpp.or= g. ------=_Part_5101_1188588797.1486345695551 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Sunday, February 5, 2017 at 10:17:51 PM UTC+8, Vicente = J. Botet Escriba wrote:
=20 =20 =20
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 = typename= MetaFu= nc<b= lahblah...>::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).

I have= no problem with decltype(return), but it's a specific solution to a si= ngle=C2=A0case. If we could have a general solution to all similar cases, I= 'd pursue it.
=C2=A0
template<blahblah..., typename Base=3Dtypenam= e MetaF= unc<= blahblah...>::type>
class Derived : public Base // yay!
{
=C2=A0 =C2=A0 // Use = `Base` from now on...
}
=C2=A0
This does not work if "blahblah...&q= uot;, 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.
=20
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_tuple(3, 4)); //Args =3D=3D {int, int}, T =3D=3D std::tuple<int, int>
template<class... Args>
void f(s= td::tup= le<A= rgs...> a, = decltype(a) b) {
=C2=A0=C2=A0=C2=A0 using T =3D decltype(a);
=C2=A0=C2=A0=C2=A0 // make use of T
}

Even thou= gh using =C2=A0decltype may make it shorter, it's still not ideal, suppose you= now have more than 2 params not just a & b.
=C2=A0
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?

The= crux of the extended typedef is that it allows you to declare both a type = and variables at once.
The idea of such a composite declaration i= s not novel, as in C++ we already have:
struct S{} s; // Decla= res type 'S' and varaible 's'

=
So I think C++ programmers should be familiar with such a style,= and extended typedef is just a natural extension of this style.
=
The simple type deduction is also an important feature of ex= tended typedef:
typedef auto T&= ref =3D getSomeRef(...);

otherwise, we have to do more verbose
auto& ref =3D getS= omeRef(...= );
using T =3D std::remove_reference_t<decltype(ref)>;

--
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/e2d22969-1510-448f-acfd-44e421fc300b= %40isocpp.org.
------=_Part_5101_1188588797.1486345695551-- ------=_Part_5100_1198539314.1486345695550-- .