220 30775 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 04:37:14 -0800 (PST) Lines: 188 Approved: news@gmane.org Message-ID: References: Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_4472_1640338671.1486298234969" X-Trace: blaine.gmane.org 1486298236 3442 195.159.176.226 (5 Feb 2017 12:37:16 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 5 Feb 2017 12:37:16 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCC3NA775MLBB7FY3TCAKGQE32VTTHY@isocpp.org Sun Feb 05 13:37:12 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ot0-f197.google.com ([74.125.82.197]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1caM47-0000do-Op for gclcip-std-proposals@m.gmane.org; Sun, 05 Feb 2017 13:37:12 +0100 Original-Received: by mail-ot0-f197.google.com with SMTP id w107sf59818325ota.6 for ; Sun, 05 Feb 2017 04:37:17 -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=OAVwBvxWuWE2zhHoqoJCevOmIDlkQ5+3DOtSTLJW47o=; b=EkQkJ1XHNOEHG5BA+NoDlUgNPoR9QnJne9qmFKW2iFeS2H/dvZTmW7lGUxb2Z+eGJT hF0qVE5e00obFo1p7sbVkqfBXHYOQOlbQRmeaz/KTaTZ7gmV0IhAZxsD8UgPOQE5jxkc R0USmJOJVI1Y3kT4EOjpJEaDXzbaO3biaE/UnZHvMeH6Fcffq0uMYvetu3cZIkUwMmAe /Y0uHsJtvHbHeogIMd+5lD1bNSkBiRO7dK3IxH9DACPSAYZTndes0hoNKSqkt6MEomas XYVygDULivPrV6yje1hHtbnryFcwWAEO/5v0kzjilxSvjRX6POhAmJV+a6D3iR1fQFyY 8hzQ== 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=OAVwBvxWuWE2zhHoqoJCevOmIDlkQ5+3DOtSTLJW47o=; b=MLtRzeOtr4Ni45f3YTQtHKxmP612u8jcG48snw3zqaWRq+bYN7H6ZrHXx9o+ez0r6Z Qv8TkWE1wZoecuuZ8oF/IvHVeNexVyMjdIsN9WepFEPvhEjtUHNSDGrYKD3yEklEl2Mp oIsKmK5lvrAUx0AOHD0fECGOKaq/pEvJxzch+vqMA+axLTlceq4YB2O1ta5aeQ7cF4KD 6xgAIgxAZU2RHEoQzJOypN4wRGZn8cMTETAIV7jazPH0NKs9NmS4m9edkcoCRLaj86pi 0A5CBlbrC48M/vH6DtwxQIbZU3seGJAiw9AS2krrVWYvC9d52PJ5TBwOpw7a4L09YJyn xcIw== 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=OAVwBvxWuWE2zhHoqoJCevOmIDlkQ5+3DOtSTLJW47o=; b=OOd9+D3UHCswJZXuW5yYBt9tMddLLWdDt8i5c7/YZClvEt5CGaorHvrCgNIEJjuAh+ d7ww8LjKPpBqms0Rsy245jxxSiVgXLriGrrva0cg0nhLk/ao/RojdJ9F1qamXeRWUrJl TsTqJNKTqI/o9DkfhFfr04nY+JccP3+yikOd4CM71FseowH1IJhQIGMDOF0d8F992lS3 8vVnOUS/vxkZqo9sC8eUzm5X9wley/iamv8xXXKN3WZuPcZxLQbI1+NytO2+Or7KCWeb KDhI38IeDNs3y6gUx8i6QhaCt1zTnRlOUVhvg8wnw4eIWDgofpzYxr+8LSInZ3MRHWDp 0Njw== X-Gm-Message-State: AIkVDXJXD9QTNa+/bpIAF7zwDHTFeMrCsZflQl9PVndvZMya1YVuDRINo8oxkjCyXC20tw== X-Received: by 10.157.15.176 with SMTP id d45mr1202672otd.71.1486298236657; Sun, 05 Feb 2017 04:37:16 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.157.39.113 with SMTP id r104ls10625117ota.8.gmail; Sun, 05 Feb 2017 04:37:15 -0800 (PST) X-Received: by 10.157.62.29 with SMTP id a29mr317315otd.5.1486298235892; Sun, 05 Feb 2017 04:37:15 -0800 (PST) In-Reply-To: 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:30775 Archived-At: ------=_Part_4472_1640338671.1486298234969 Content-Type: multipart/alternative; boundary="----=_Part_4473_1044448251.1486298234970" ------=_Part_4473_1044448251.1486298234970 Content-Type: text/plain; charset=UTF-8 Hi Bengt, Thanks for bringing this thread up :) On Sunday, February 5, 2017 at 6:03:46 PM UTC+8, Bengt Gustafsson wrote: > > I like it, but it does take some getting used to the stacking of > identifiers in parameter and variable declaration cases. Also, in these > cases, I suspect there could be some parsing issues, especially if the name > of the type is defined in an outer scope. Maybe you'd have to > clarify why this is not a problem. Then again, I can't really produce a > problematic example so maybe I'm just seeing ghosts here. However, an > example involving an array size bracket would be interesting as it comes > after the identifier. > If the parser sees a second unqualified id (possibly preceded by some '*' or '&') after the typedef declarator, the second one will be interpreted as the declarator of the type that the typedef declarator declares. typedef int A[2] a; // A == int[2], decltype(a) == A typedef int F(int) f; // F == int(int), decltype(f) == F typedef int A a[2]; // A == int, decltype(a) == int[2] typedef int F f(int); // F == int, decltype(f) == int(int) > This brings up a wrinkle in the last example: > > typedef int* P p1 = nullptr, p2 = nullptr, *p3 = nullptr; // p1 & p2 are > both `int*`, and p3 is `int**` > > Here you must make it clear that there is a new rule in play compared to > what would be the most logical interpretation compared to current language > rules: That the * would only apply to the next identifier being declared. > That's actually not changed. In this case, the next identifier being declared is `P`, which is in turn, the decl-specifier of the subsequent variables. Instead the new rule is as you explain, which is necessary for the use case > of return type. > -- 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 email 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/a316ab77-56ff-4fcc-a3d9-ddfcdf1aae5e%40isocpp.org. ------=_Part_4473_1044448251.1486298234970 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Bengt,

Thanks for bringing this thre= ad up :)

On Sunday, February 5, 2017 at 6:03:46 PM UTC+8, Bengt Gust= afsson wrote:
= I like it, but it does take some getting used to the stacking of identifier= s in parameter and variable declaration cases. Also, in these cases, I susp= ect there could be some parsing issues, especially if the name of the type = is defined in an outer scope. Maybe you'd have to
clarify why this = is not a problem. Then again, I can't really produce a problematic exam= ple so maybe I'm just seeing ghosts here. However, an example involving= an array size bracket would be interesting as it comes after the identifie= r.

If the parser sees a second = unqualified id (possibly preceded by=C2=A0some '*' or '&= 9;) after the typedef declarator, the second one will be interpreted as the= declarator of the type that the typedef=C2=A0declarator=C2=A0declares.

typedef int A[2] a; = // A =3D=3D=C2=A0int[2], decltype(a) =3D=3D A
typedef int F(int) f; // F =3D=3D int(int),=C2=A0decltype(f) =3D=3D F

typedef=C2=A0int=C2=A0= A a[2];=C2=A0// A =3D=3D int, decltype(a) =3D=3D= =C2=A0int[2]
typedef int F f(int); //=C2=A0F =3D=3D int,=C2=A0decltype(f) =3D=3D=C2=A0int(int)
=

=C2=A0
This brings up a wrinkle in the last example:

typedef=C2=A0in= t*=C2=A0P p1=C2=A0=3D<= /span>=C2=A0nullptr,=C2=A0p2=C2=A0=3D=C2=A0nullptr,=C2=A0*p3=C2=A0<= /span>=3D=C2=A0nullptr;=C2=A0// p1 & p2 are both `i= nt*`, and p3 is `int**`

Here you must make it clear that there is a new rule in pl= ay compared to what would be the most logical interpretation compared to cu= rrent language rules: That the * would only apply to the next identifier be= ing declared.

That= 's actually not changed. In this case, the=C2=A0next identifier being d= eclared is `P`, which is in turn, the decl-specifier of the subsequent vari= ables.

Instead = the new rule is as you explain, which is necessary for the use case of retu= rn type.

--
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/a316ab77-56ff-4fcc-a3d9-ddfcdf1aae5e= %40isocpp.org.
------=_Part_4473_1044448251.1486298234970-- ------=_Part_4472_1640338671.1486298234969-- .