220 11460 article Path: news.gmane.org!not-for-mail From: Matthew Fioravante Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Named function parameters using anonymous structs for C and C++ Date: Mon, 16 Jun 2014 19:46:10 -0700 (PDT) Lines: 299 Approved: news@gmane.org Message-ID: References: <72c49240-547b-4bf6-8b27-aff6a61c1272@isocpp.org> <36D3B24B-7F24-4ED5-A27C-F4EF71CF244C@gmail.com> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_2016_7386306.1402973170506" X-Trace: ger.gmane.org 1402973180 13129 80.91.229.3 (17 Jun 2014 02:46:20 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 17 Jun 2014 02:46:20 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDELF54RTIGRB46X72OAKGQE54RR43Y@isocpp.org Tue Jun 17 04:46:13 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-oa0-f69.google.com ([209.85.219.69]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1WwjPY-0004FU-JT for gclcip-std-proposals@m.gmane.org; Tue, 17 Jun 2014 04:46:12 +0200 Original-Received: by mail-oa0-f69.google.com with SMTP id j17sf37646277oag.4 for ; Mon, 16 Jun 2014 19:46:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :list-post:list-help:list-archive:list-subscribe:list-unsubscribe :content-type; bh=qwTuN0CN/99ouxHWVfdhdoB1eZMtzaf2iQOps/uMXJQ=; b=IHUZTNAKk9BApx5iRs471L0pbrpkFiG+tjAH359+vuNOzixQAgJxk+SXIPcjDuTFUK mUmGdnvzcMRBJuRj/MX4rwKLziNSzQVaGRRyvlqCMMLCsmz0mPhowOjobVhbB5/MjPZR 7T6XxJNd5LGpDur1uNwK8DJZUJmj1bFT9wHCIlLhprQrw7QAEToSLzweJJgN9t2bMI+q JZXOswzuDBnk5ExVz48vy6/hRqhLCd39z9CPfUgRLUH1pQa3O3/W3EuslTRqFtR/y+wG q+a6ERtl1CQaRq8lbL1cPCnCF7gt4mu8PHeBi3qcJhrAa1bB7dGPvCUUWu+FLttycRcY ARMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; 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:list-post:list-help:list-archive :list-subscribe:list-unsubscribe:content-type; bh=qwTuN0CN/99ouxHWVfdhdoB1eZMtzaf2iQOps/uMXJQ=; b=EExViu+EpUcFFhuMj6gQ9sXsZV+BgUmTp5J/EJ+q8qctWOGVD9CVUdUMm3aSoT7cA7 oDlCUh+BCxQROYB/Q++7Tor2zRYGopu7W3yo2yiP9erEWZjFlc3Lqyzqh/4UIvlOI1IB PzZ3e0W0vcC24QUvSSwUfmBsPhPEpgqPH3cZwgsihv2lM2HpSv0j3Wgx0pyMovB/Ktgr l5gAIOauNNzeORDezOgsj2CjFuCGKtWPBgSNRWbvVUMn4jxVy6gEF0A+kB9KhhRioVt8 v+SdzAPnhdKboHlSabOwa1muPmu76n4brPR37ygQdh7EWeRfzLUAcEIZlLBio0F1900c UZuw== X-Gm-Message-State: ALoCoQmRHxcCmKEZE3igf+Rv8ru+y/wa5UhZZpopjkf7wSAFJOEYiX7MkocAdryactn05NiAKITe X-Received: by 10.50.56.74 with SMTP id y10mr561516igp.3.1402973171609; Mon, 16 Jun 2014 19:46:11 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.140.25.225 with SMTP id 88ls560540qgt.85.gmail; Mon, 16 Jun 2014 19:46:11 -0700 (PDT) X-Received: by 10.140.80.5 with SMTP id b5mr1724qgd.20.1402973171075; Mon, 16 Jun 2014 19:46:11 -0700 (PDT) In-Reply-To: <36D3B24B-7F24-4ED5-A27C-F4EF71CF244C@gmail.com> X-Original-Sender: fmatthew5876@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:11460 Archived-At: ------=_Part_2016_7386306.1402973170506 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Monday, June 16, 2014 9:52:38 PM UTC-4, David Krauss wrote: > > > On 2014=E2=80=9306=E2=80=9317, at 9:37 AM, David Krauss >=20 > wrote: > > > On 2014=E2=80=9306=E2=80=9317, at 5:43 AM, corentin....@cea.fr wrote: > > Le lundi 16 juin 2014 21:18:52 UTC+2, Matthew Fioravante a =C3=A9crit : >> >> That also implies adding support for C tagged structure initialization t= o=20 >> C++, which implies defining how it works with constructors. At first pas= s,=20 >> I'd say only enable the syntax for POD structs. This would need to be=20 >> studied very carefully. I wouldn't be surprised if this was already brou= ght=20 >> up in the past, studied, and rejected for some reason. Does anyone have= =20 >> insight on that? Google doesn't appear to be helpful. >> > > A proposal has been written recently: > > https://groups.google.com/a/isocpp.org/forum/#!msg/std-proposals/IgDFqKjK= lRs/CGARpDJy9JsJ=20 > I do not know what is the current status of that proposal though. > > > It would probably be better to make a clean start, based on review of=20 > discussions on this forum. > > Note, I was advocating the designated initializer solution earlier in thi= s=20 > thread but nobody seemed to care at the time. Anyone who=E2=80=99s intere= sted might=20 > check those posts. > > > Oh, it was the other thread. And my strongest point was that, even if=20 > named parameters are implemented separately from pass-by-struct, folks wi= ll=20 > still combine designated initializers with pass-by-struct anyway. This=20 > results in two similar ways of doing the same thing, which should have=20 > similar if not same syntax. > I completely agree with you that we must reuse designated initializer=20 syntax. Having 2 different syntax just complicates the language. Its=20 completely necessary. There's no bike shed to be painted here! =20 > =20 > > This thread seems to be simply taking the alternative idea and running=20 > with it. :) > > One suggestion, but it=E2=80=99s only that: the struct is the sole argume= nt, then=20 > allow designated initializer syntax directly in the argument list =E2=80= =94 i.e.,=20 > allow brace elision. > > struct rect { > int top, left, bottom, right; > > rect( /* struct */ { int in_top, in_left, in_bottom, in_right; } ) > : top( in_top ), left( in_left ), bottom( in_bottom ), right(=20 > in_right ) {} > > rect( /* struct */ { int in_top, in_left, in_height, in_width; } ) > : top( in_top ), left( in_left ) > , bottom( in_top + in_width ), right( in_left + in_width ) {} > }; > > rect a( .top =3D 4, .height =3D 43, .left =3D 10, .width =3D 100 ); > rect b( .top =3D 4, .bottom =3D 47, .left =3D 10, .right =3D 110 ); > > The original style: int foo(int a, int b, string c); foo(.a =3D 0, .b =3D 1, .c =3D "Hello");=20 Pros: - Very simple - No ABI changes - All legacy code immediately becomes named function enabled Cons: - Cannot use named syntax when calling via a function pointer, since the=20 type has no concept of parameter names. - Requires some language changes to enable the callsite syntax - Argument names while not part of the ABI, are now part of the API. You=20 cannot change the names or you will break callers.=20 - All legacy code immediately becomes named function enabled. The struct approach int foo(int a, {int b; int c;}, } Pros: -Separates positional and named arguments. Is this desirable?? -No ABI changes again, just reuses the type system with anonymous structs -Function pointers can also be name initialized when called, since their=20 type encodes the type of the struct, and the struct can be initialized=20 using tagged init syntax. This sounds like a big win. -No special rules, all syntax inherited from struct Cons; -Functions with same arguments still have different types. -Requires anonymous structs proposal -If you have 2 overloads, with same positional arguments and different=20 structs, how do you choose which one to pick from initializer syntax?=20 void foo(int a, {int b; int c;}); void foo(int a, {string b=3D"", string c=3D""}); foo(1, {.c =3D "hello" }); I suppose the naming rule here could try to initialize each instance of foo= =20 using the brace expression in order of appearance in an SFINAE like manner. > I=E2=80=99d also help draft such a proposal if someone wants a collaborat= or.=20 Right now I=E2=80=99m hoping to attend the November meeting > in Champaign,= =20 although it=E2=80=99s not a guarantee and I might have a full plate with ot= her=20 proposals. However, at this point a > paper exploring the design space might be more appropriate than an=20 attempt at fully-baked wording, which reduces the=20 > burden of advocacy. There are a number of issues and corner cases to=20 check, and the committee needs to approve the=20 > =E2=80=9Cwhat=E2=80=9D before the =E2=80=9Chow.=E2=80=9D Does it make sense to cram all of these sort of unrelated things into one= =20 big proposal? Or do it incrementally with multiple proposals with the big= =20 picture in mind? I could start writing one or help with writing one and fleshing out the=20 details. It would be great to have someone actually present it at the=20 meetings, since I don't actually have the ability to attend myself. --=20 ---=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. Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa= ls/. ------=_Part_2016_7386306.1402973170506 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Monday, June 16, 2014 9:52:38 PM UTC-4, David K= rauss wrote:

On 2014=E2=80=9306=E2=80=9317, at 9:37 AM, = David Krauss <pot...@gmail.com&= gt; wrote:


On 2014=E2=80=9306=E2=80=9317, at 5:43 AM, corentin....@cea.fr wrote:

Le lundi 16 juin 2014 21:18:52 UTC+2, Mat= thew Fioravante a =C3=A9crit :
That also implies adding support for C tagged structure i= nitialization to C++, which implies defining how it works with constructors= .. At first pass, I'd say only enable the syntax for POD structs. This would= need to be studied very carefully. I wouldn't be surprised if this was alr= eady brought up in the past, studied, and rejected for some reason. Does an= yone have insight on that? Google doesn't appear to be helpful.

A proposal has been written recently:
https://gro= ups.google.com/a/isocpp.org/forum/#!msg/std-proposals/IgDFqKjKlRs= /CGARpDJy9JsJ
I do not know what is the current status of that= proposal though.

It would proba= bly be better to make a clean start, based on review of discussions on this= forum.

Note, I was advocating the designated initializer sol= ution earlier in this thread but nobody seemed to care at the time. Anyone = who=E2=80=99s interested might check those posts.
<= div>
Oh, it was the other thread. And my strongest point was = that, even if named parameters are implemented separately from pass-by-stru= ct, folks will still combine designated initializers with pass-by-struct an= yway. This results in two similar ways of doing the same thing, which shoul= d have similar if not same syntax.

<= /div>
I completely agree with you that we must reuse d= esignated initializer syntax. Having 2 different syntax just complicates th= e language. Its completely necessary. There's = no bike shed to be painted here!
 
 

This thread seems to be simply taking t= he alternative idea and running with it. :)

One su= ggestion, but it=E2=80=99s only that: the struct is the sole argument, then= allow designated initializer syntax directly in the argument list =E2=80= =94 i.e., allow brace elision.

struct rect {
    int= top, left, bottom, right;

    rect( /* struct */ { int= in_top, in_left, in_bottom, in_right; } )
        : top( in_top ), left( in_left ), botto= m( in_bottom ), right( in_right ) {}

    rect( /* struc= t */ { int in_top, in_left, in_height, in_width; } )
        : top( in_top ), left( in_lef= t )
        , b= ottom( in_top + in_width ), right( in_left + in_width ) {}
};

rect a( .top =3D 4, .height =3D 43, .l= eft =3D 10, .width =3D 100 );
= rect b( .top =3D 4, .bottom =3D 47, .left =3D 10, .right =3D 110 );<= /div>


The = original style:

int foo(int a, int b, string c);
foo(.a =3D 0, .b =3D 1, .c =3D "Hello"); 

Pros:
- Very simple
- No ABI changes
- = All legacy code immediately becomes named function enabled
Cons:<= /div>
- Cannot use named syntax when calling via a function pointer, si= nce the type has no concept of parameter names.
- Requires some l= anguage changes to enable the callsite syntax
- Argument names wh= ile not part of the ABI, are now part of the API. You cannot change the nam= es or you will break callers. 
- All legacy code immediately= becomes named function enabled.

The struct approa= ch
int foo(int a, {int b; int c;}, }

Pro= s:
-Separates positional and named arguments. Is this desirable??=
-No ABI changes again, just reuses the type system with anonymou= s structs
-Function pointers can also be name initialized when ca= lled, since their type encodes the type of the struct, and the struct can b= e initialized using tagged init syntax. This sounds like a big win.
-No special rules, all syntax inherited from struct
Cons;
-Functions with same arguments still have different types.
= -Requires anonymous structs proposal
-If you have 2 overloads, wi= th same positional arguments and different structs, how do you choose which= one to pick from initializer syntax? 

void f= oo(int a, {int b; int c;});
void foo(int a, {string b=3D"", strin= g c=3D""});

foo(1, {.c =3D "hello" });
<= br>
I suppose the naming rule here could try to initialize each i= nstance of foo using the brace expression in order of appearance in an SFIN= AE like manner.


> I=E2=80=99d al= so help draft such a proposal if someone wants a collaborator. Right now I= =E2=80=99m hoping to attend the November meeting > in Champaign, althoug= h it=E2=80=99s not a guarantee and I might have a full plate with other pro= posals. However, at this point a
> paper exploring the design = space might be more appropriate than an attempt at fully-baked wording, whi= ch reduces the 
> burden of advocacy. There are a number = of issues and corner cases to check, and the committee needs to approve the=  
> =E2=80=9Cwhat=E2=80=9D before the =E2=80=9Chow.=E2=80= =9D

Does it make sense to cram all of these so= rt of unrelated things into one big proposal? Or do it incrementally with m= ultiple proposals with the big picture in mind?

I could start writing one or help with writing one and fleshing out the d= etails. It would be great to have someone actually present it at the meetin= gs, since I don't actually have the ability to attend myself.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/<= /a>.
------=_Part_2016_7386306.1402973170506-- .