220 11478 <97dfc150-6ae5-4494-bed5-3f4f5fed84fa@isocpp.org> 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: Tue, 17 Jun 2014 08:52:48 -0700 (PDT) Lines: 178 Approved: news@gmane.org Message-ID: <97dfc150-6ae5-4494-bed5-3f4f5fed84fa@isocpp.org> References: <72c49240-547b-4bf6-8b27-aff6a61c1272@isocpp.org> <36D3B24B-7F24-4ED5-A27C-F4EF71CF244C@gmail.com> <29C6D83B-BD31-42A9-B7BD-2C797E3FE58C@gmail.com> <0bf9fa1c-db92-4f3c-bb2f-627e8b4e6135@isocpp.org> <671A8CDD-7805-410F-94A0-62DEBD78D1C0@gmail.com> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_457_19075104.1403020369085" X-Trace: ger.gmane.org 1403020381 1881 80.91.229.3 (17 Jun 2014 15:53:01 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 17 Jun 2014 15:53:01 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDELF54RTIGRBUWIQGOQKGQESWHZN5A@isocpp.org Tue Jun 17 17:52:55 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-qa0-f72.google.com ([209.85.216.72]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Wwvgp-0001cW-Rs for gclcip-std-proposals@m.gmane.org; Tue, 17 Jun 2014 17:52:52 +0200 Original-Received: by mail-qa0-f72.google.com with SMTP id i13sf22806384qae.3 for ; Tue, 17 Jun 2014 08:52:51 -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=P2B0QT8grtlmK+iaeudZGMVfgV4Wgq0oSTkezdprZjk=; b=blnP0+ogY7TwEEHmscK/71r9A4VhY2tskY/dETwi1X+P230snlOvBx48f4Vx6XJGQp enirzTMLdyQlBLbgu9oM7KmJGd7ehz6iZmM+L/e1BStuphOGSdRlXmggkslDJd/f7hcj pM/Bprok/boLNBwFd5teSOtO3ENXsGxU0y+FGwdtpsOdVOrk39azbwpnofjoE+1eWGDH jbStbZlkmOE8jGmkfCEy1dIO/WzibkRd2IdBfxl14b8aIDPVii4WhwDqkjEiF26f2CbC 5OtxOo/QyDhGime+gbCNBoW6qf/nir2lS58P8Mj7nVXQ1l14eUiksRjVhrzKES0bh1t/ I6PQ== 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=P2B0QT8grtlmK+iaeudZGMVfgV4Wgq0oSTkezdprZjk=; b=Gaj4weHBCIjdhb6O/yy+vqWZxHOnRJO0zKo8EOC1n+HDwYW+Vrwp1Mv2RldKQsAE0s EXyjqi7o/VkkGsbtWbe7nXwEAbJmG5DdJUPYYVqnTQ7AzpuoibUfANP7rvxPiAUI27H6 dcNZvuGSJa1pS2CCJj7PJvi6j6XGdcv9rZ9hLFUVRAjVJ+qP1E1z6pViWFXlJuHVQ01V 80MmRKZzMO1C2ojuof65qA9aJSPzgHW+CBWcU9zSYlXKCKIhVMXfDWeEssksxcXXwTm/ HKaGmtGsNvBWT03keB1T8uBH6nx7sPc1OD8YFm0m/vqLZxCvF0VqHGeNyjEpn3zpagaS mo3g== X-Gm-Message-State: ALoCoQkqJc30pfxTuhtseuaasxB54bXqK3dDD0mjpPlb/5Ef4D/uREepfDG0KNpdEyUO5Aqi0RGY X-Received: by 10.58.65.38 with SMTP id u6mr576784ves.16.1403020371082; Tue, 17 Jun 2014 08:52:51 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.140.38.133 with SMTP id t5ls4871015qgt.43.gmail; Tue, 17 Jun 2014 08:52:50 -0700 (PDT) X-Received: by 10.140.92.77 with SMTP id a71mr484783qge.0.1403020370408; Tue, 17 Jun 2014 08:52:50 -0700 (PDT) In-Reply-To: <671A8CDD-7805-410F-94A0-62DEBD78D1C0@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:11478 Archived-At: ------=_Part_457_19075104.1403020369085 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tuesday, June 17, 2014 11:21:51 AM UTC-4, David Krauss wrote: > > > On 2014=E2=80=9306=E2=80=9317, at 10:59 PM, Matthew Fioravante > wrote: > > As I'm working on the paper and thinking about the details of the=20 > proposal, I've found a few issues to wrestle with. > > The major difference between aggregate initialization and a set of what I= =20 > call in the paper compiler generated "aggregate member constructors": > > Aggregates can be left in an uninitialized state by not specifying an=20 > initializer. If we drop aggregate initialization in favor of constructors= ,=20 > we still need to support this behavior. > > > Who is =E2=80=9Cwe=E2=80=9D? Surely you don=E2=80=99t mean dropping it fr= om the standard, but=20 > you=E2=80=99re just considering the case when the user is migrating a cla= ss from=20 > from aggregate to constructor? > > Hmm. Checking the draft: > > First, this syntax is yet another *special case* inherited for C=20 > compatibility. These compatibility cases complicate the standard and the= =20 > learning curve for C++ developers. It would be better if this feature cou= ld=20 > be reimplemented using already existing C++ rules and mechanisms and stil= l=20 > retain C compatibility. > > This seems to be veering away from the problem statement. =E2=80=9CNewer = would be=20 > better=E2=80=9D is not much of a motivation. You need to clearly state wh= at=E2=80=99s=20 > broken before going down this path. For what it=E2=80=99s worth, aggregat= e=20 > initialization has been maintained just as carefully as the rest of the= =20 > language. > The idea is that if aggregate initialization for class types can be=20 completely reproduced by compiler generated constructors, we don't actually= =20 need it. This is a side question and not too important.=20 > > Named function parameters using structs chicken and egg problem: > > If we had named function params, aka: > > int foo(int a, int b, int c); > foo(.a =3D 1, .b =3D 2, .c =3D 4); > > Then having designated initializers for structs would just fall out from= =20 > this in the constructors. > > If we introduce designated initializers first, then named function=20 > parameters are derived from that. I'm falling more and more into the seco= nd=20 > camp because as I think about it, separating positional and named argumen= ts=20 > seems to make a lot of sense.=20 > > > This seems to be the same as what you=E2=80=99ve been saying throughout t= his=20 > thread. Is there a problem or are you affirming the previous ideas? I=E2= =80=99m a=20 > little confused. Also I don=E2=80=99t see how this relates to what=E2=80= =99s in the posted=20 > draft so far. > > I have not written about named arguments yet in my draft. I'm mostly=20 thinking out loud. It seems like everyone here is in the struct argument=20 passing camp. If anyone has strong opinions either way, I'd love to hear=20 it.=20 --=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_457_19075104.1403020369085 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tuesday, June 17, 2014 11:21:51 AM UTC-4, David= Krauss wrote:

On 2014=E2=80=9306=E2=80=9317, at 10:59 P= M, Matthew Fioravante <fmatth...@gm= ail.com> wrote:

= As I'm working on the paper and thinking about the details of the proposal,= I've found a few issues to wrestle with.

The major difference betwe= en aggregate initialization and a set of what I call in the paper compiler = generated "aggregate member constructors":

Aggregates can be left in= an uninitialized state by not specifying an initializer. If we drop aggreg= ate initialization in favor of constructors, we still need to support this = behavior.

Who is =E2=80=9Cwe=E2= =80=9D? Surely you don=E2=80=99t mean dropping it from the standard, but yo= u=E2=80=99re just considering the case when the user is migrating a class f= rom from aggregate to constructor?

Hmm. Checking t= he draft:

First, this syntax is yet = another special case inherited for C compatibility. These compatibility cases complicate the standard and the learning curve for C++ developers. It would be better if this feature could be reimplemented using already existing C++ rules and mechanisms and still retain C compatibility.

This seems to = be veering away from the problem statement. =E2=80=9CNewer would be better= =E2=80=9D is not much of a motivation. You need to clearly state what=E2=80= =99s broken before going down this path. For what it=E2=80=99s worth, aggre= gate initialization has been maintained just as carefully as the rest of th= e language.

The idea is that if aggr= egate initialization for class types can be completely reproduced by compil= er generated constructors, we don't actually need it. This is a side questi= on and not too important.

Named function parameters using structs chicken and egg = problem:

If we had named function params, aka:

int foo(int a,= int b, int c);
foo(.a =3D 1, .b =3D 2, .c =3D 4);

Then having de= signated initializers for structs would just fall out from this in the cons= tructors.

If we introduce designated initializers first, then named = function parameters are derived from that. I'm falling more and more into t= he second camp because as I think about it, separating positional and named= arguments seems to make a lot of sense.

This seems to be the same as what you=E2=80=99ve been saying throu= ghout this thread. Is there a problem or are you affirming the previous ide= as? I=E2=80=99m a little confused. Also I don=E2=80=99t see how this relate= s to what=E2=80=99s in the posted draft so far.


I have not written about named arguments yet in my draft. I= 'm mostly thinking out loud. It seems like everyone here is in the struct a= rgument passing camp. If anyone has strong opinions either way, I'd love to= hear it.

--

---
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_457_19075104.1403020369085-- .