220 19944 <3a2aeb70-24c2-4a00-8c94-f6db5f3ca6b6@isocpp.org> article Path: news.gmane.org!not-for-mail From: Nicol Bolas Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: default arguments Date: Thu, 20 Aug 2015 06:57:11 -0700 (PDT) Lines: 323 Approved: news@gmane.org Message-ID: <3a2aeb70-24c2-4a00-8c94-f6db5f3ca6b6@isocpp.org> References: <89bf9d09-00ed-45db-bf88-39c844707bd1@isocpp.org> <5F6E90B3-44BE-4A37-BE8F-91E1255E6407@gmail.com> <124ba022-8377-4ba3-be25-23e2134a9549@isocpp.org> <920F56A3-A113-45D4-9CFF-98B941F013C5@gmail.com> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_7376_339109379.1440079031471" X-Trace: ger.gmane.org 1440079035 24808 80.91.229.3 (20 Aug 2015 13:57:15 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 20 Aug 2015 13:57:15 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCEKFTV6ZUMBBOFZ26XAKGQERC4EAZY@isocpp.org Thu Aug 20 15:57:15 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-qg0-f72.google.com ([209.85.192.72]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZSQLC-0000eP-Hs for gclcip-std-proposals@m.gmane.org; Thu, 20 Aug 2015 15:57:14 +0200 Original-Received: by qgj62 with SMTP id 62sf36252404qgj.3 for ; Thu, 20 Aug 2015 06:57:13 -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 :content-type: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=2hZqZQAGnobgIAd7sb9oUFutoPijLUKeHklloftx80w=; b=gjuCJdflm6my0dTCADnSM8JtcHrn1g3YqjHiQ+aa8Ye6vTRTHKdFNKMyGL7Hm+9YQx Mm7wKLAr9skqnJ9wPpHfI2sVombdFW/lXT+/u4Vf+VdnWekEgMHZSkEwhB00VTuY6LJZ ZKdLdV7koyNCgsmqW4bDOqCNatVx7Pvx53NflM8KU9CfbEtXOC+3fOajGmKJy6Ln9zd3 OFstwe7lJo3ZgZQ9i+ykalBelbJmzR4WCqMXGd+zGJZpuHC6hx4z4LAIV7Wwzia45SRB eQXdFPuMy5wonmFs7vHgXrTAWpDVQEWcpLQZMDh9VM09e/rxLJ2rsg5ZiCjqsLvNf6jn KIIA== 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:content-type: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=2hZqZQAGnobgIAd7sb9oUFutoPijLUKeHklloftx80w=; b=ZqqHU7qdlNgKQtxayqlMaPR2JssPDgd0AXaWCtI0OuOoxjAGS6hP74zK6I3TyKG42X avjNR2VDaGmyhrE7lII7rR84arh7dHhdSFbImQqW6NSRWGuI/dYsq3wpkYRUlzvenk51 krtJLOHJF4n+rNLh4YbIHJGTSsPuuPDLPIxH2I18LLSu/vLYpOyQ6jQ51QllMDibWXzM 7gCYhEoa1Y+Erl5XVe8m1hPR13JITlE9dRPyzKftGF/IF5ls0oq+wa0dqKV9/VGll32N qi86TTaQRZeiQ9LgzUruY0ZZvqmK1t5FSrkXtmQ5AZg3MJnyyjCWh4GMTTK58tIDtC7z 9GwA== X-Gm-Message-State: ALoCoQk2DvH4E/4Vww8O0UooB7kDs4E3qkBoTE66Ovk11mcF/2WuCHVzYfOu6EKTjUA7JkEshOJN X-Received: by 10.140.234.81 with SMTP id f78mr2356270qhc.9.1440079033439; Thu, 20 Aug 2015 06:57:13 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.182.106.201 with SMTP id gw9ls381037obb.16.gmail; Thu, 20 Aug 2015 06:57:12 -0700 (PDT) X-Received: by 10.182.245.165 with SMTP id xp5mr25818obc.31.1440079032308; Thu, 20 Aug 2015 06:57:12 -0700 (PDT) In-Reply-To: <920F56A3-A113-45D4-9CFF-98B941F013C5@gmail.com> X-Original-Sender: jmckesson@gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Spam-Checked-In-Group: std-proposals@isocpp.org 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:19944 Archived-At: ------=_Part_7376_339109379.1440079031471 Content-Type: multipart/alternative; boundary="----=_Part_7377_1367054356.1440079031472" ------=_Part_7377_1367054356.1440079031472 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thursday, August 20, 2015 at 3:11:02 AM UTC-4, David Krauss wrote: > > > On 2015=E2=80=9308=E2=80=9320, at 11:59 AM, Nicol Bolas >=20 > wrote: > > What you're doing is enforcing a single struct policy, which is not=20 > something I would want to see advocated or become commonplace. However, i= t=20 > does lack the terrible syntactic noise of the C version, so it's already= =20 > ahead of the curve ;) > > > One is better than zero=E2=80=A6 but what=E2=80=99s the impediment to gro= uping by nested=20 > sub-aggregates? > > The problem with that is that NSDMI's operate by effectively modifying=20 > constructors.=20 > > > Since C++14, NSDMIs have a second method of action, by aggregate=20 > initialization. They are already allowed in aggregates. > I did not know this. I'm not sure how I missed that one, since my browser= =20 history clearly showed that I found N3653... =20 > > As for the implicit braces thing, that sounds like a very bad idea.=20 > Uniform initialization already has way too many implicit braces, to the= =20 > point where it actually gets non-uniform. It's two extra characters; I=20 > don't see it as provoking that much syntactic noise. > > > Hmm, are you for the proposal or against? Implicit braces are the entiret= y=20 > of it. (Note that Clang and GCC already implement designated initializers= ,=20 > both only issuing a warning under -pedantic.) > The fact that Clang and GCC implement designated inititalizers does not=20 make them actual features of the C++ standard. So you can't propose a=20 change that requires non-standard functionality. Thus, this proposal *must include* designated initializers for aggregates. =20 > And they specifically don=E2=80=99t apply under brace (uniform) initializ= ation. > I don't know which "they" you're referring to: designated initializers or= =20 brace elision. I'm going to assume that you mean to say that designated=20 initializers should be restricted to function calls, without explicit=20 braced-init-lists. If that's not the case, then just ignore this section. Given that, I like it even less now. You're devising very special-case=20 syntax when there's no real need for it. Plus even though you're=20 initializing an object, you explicitly *cannot* use uniform initialization= =20 syntax for it. You're making uniform initialization even less uniform than it already was.= =20 Do we really need to do that? I think your idea is imposing limitations on this functionality that just= =20 don't need to exist. Just provide designated initializers in C++ aggregate= =20 initialization syntax, period. Since NSDMIs in C++14 don't prevent=20 something from being an aggregate or undergoing aggregate initialization,= =20 just proceed forward from there. Not only do you get something like named= =20 parameters, you also get generalized designated initalizers for aggregate= =20 initialization. Oh sure, you'll still need the braces: `f({...})`. But that's fine, since= =20 it makes it clear to the user exactly what you're doing. By requiring the braces, by making the object initialization more clear, it= =20 *also* solves the function overloading problem, since generalized=20 designated initializer syntax would give you the ability to specify which= =20 set of parameters to use: f(param_set1{...}); f(param_set2{...}); I don't like the idea of hacking up a "solution" to named parameters this= =20 way (admittedly, a solution that many other languages use). But I'd be much= =20 happier with this if such a solution was just a natural outgrowth of a=20 generally useful feature like designated aggregate initializers. That is, you get designated initializers, which *could* be used for named= =20 parameters, rather than getting named parameters by a very restricted use= =20 of designated initializers. It feels less like a hack that way. The problem with adding designated initializers alone is that they enhance= =20 > aggregates but not classes with constructors. This impedes refactoring an= =20 > aggregate into a non-aggregate, which is a very common operation. > That is something of a danger, yes. But I would rather find a way to=20 mitigate *that* problem than to deliberately gimp the functionality. Here's a possible solution: If the initializer list contains designated initializers, then it will=20 attempt to use aggregate initialization on the target object type. If the= =20 target object is not an aggregate, then it will check all of the=20 constructors for the target. If it finds a constructor that takes only one= =20 parameter (minus defaults of course) which *is* an aggregate, then it will= =20 initialize an aggregate and pass it to that constructor. You could even recursively apply those rules. If a constructor takes one=20 argument that has a constructor that takes one argument that has a=20 constructor that takes one argument that is an aggregate, then the=20 initializer list constructs that type, passes it to the next object, then= =20 passes the result to the next, and so on. That way, when you refactor an aggregate into a non-aggregate, all you need= =20 to do is create a throwaway aggregate that matches the old aggregate, which= =20 your now-non-aggregate type uses for named parameter object initialization. Thus, *any* non-aggregate could be initialized like this: non_aggregate nagg =3D {.param1 =3D 20, .param3 =3D 50}; Yeah, this suggestion effectively uses brace elision, which I despise. But= =20 it does solve the problem, and it gives us nice functionality that your=20 more limited approach would not have provided. --=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_7377_1367054356.1440079031472 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thursday, August 20, 2015 at 3:11:02 AM UTC-4, David Krauss wrote:
=

On 2015=E2=80=9308=E2=80=9320,= at 11:59 AM, Nicol Bolas <jmck...@gmail.com> wrote:

What you're doing is enforcing a single struct policy, which is not s= omething I would want to see advocated or become commonplace. However, it d= oes lack the terrible syntactic noise of the C version, so it's already= ahead of the curve ;)

One = is better than zero=E2=80=A6 but what=E2=80=99s the impediment to grouping = by nested sub-aggregates?

The = problem with that is that NSDMI's operate by effectively modifying cons= tructors.

Since C++14, NSDMIs = have a second method of action, by aggregate initialization. They are alrea= dy allowed in aggregates.

I di= d not know this. I'm not sure how I missed that one, since my browser h= istory clearly showed that I found N3653...
=C2=A0
=
As for the implicit braces thing, t= hat sounds like a very bad idea. Uniform initialization already has way too= many implicit braces, to the point where it actually gets non-uniform. It&= #39;s two extra characters; I don't see it as provoking that much synta= ctic noise.

Hmm, are you f= or the proposal or against? Implicit braces are the entirety of it. (Note t= hat Clang and GCC already implement designated initializers, both only issu= ing a warning under -pedantic.)

The fact t= hat Clang and GCC implement designated inititalizers does not make them act= ual features of the C++ standard. So you can't propose a change that re= quires non-standard functionality.

Thus, this proposal must inclu= de designated initializers for aggregates.
=C2=A0
An= d they specifically don=E2=80=99t apply under brace (uniform) initializatio= n.

I don't know which "they"= you're referring to: designated initializers or brace elision. I'm= going to assume that you mean to say that designated initializers should b= e restricted to function calls, without explicit braced-init-lists. If that= 's not the case, then just ignore this section.

Given that, I li= ke it even less now. You're devising very special-case syntax when ther= e's no real need for it. Plus even though you're initializing an ob= ject, you explicitly cannot use uniform initialization syntax for it= ..

You're making uniform initialization even less uniform than it= already was. Do we really need to do that?

I think your idea is imp= osing limitations on this functionality that just don't need to exist. = Just provide designated initializers in C++ aggregate initialization syntax= , period. Since NSDMIs in C++14 don't prevent something from being an a= ggregate or undergoing aggregate initialization, just proceed forward from = there. Not only do you get something like named parameters, you also get ge= neralized designated initalizers for aggregate initialization.

Oh su= re, you'll still need the braces: `f({...})`. But that's fine, sinc= e it makes it clear to the user exactly what you're doing.

By re= quiring the braces, by making the object initialization more clear, it a= lso solves the function overloading problem, since generalized designat= ed initializer syntax would give you the ability to specify which set of pa= rameters to use:

<= div class=3D"subprettyprint">f(param_= set1{...})= ;
f(param_set2{...});

I don't like the idea of hacking up a "solution"= ; to named parameters this way (admittedly, a solution that many other lang= uages use). But I'd be much happier with this if such a solution was ju= st a natural outgrowth of a generally useful feature like designated aggreg= ate initializers.

That is, you get designated initializers, which could be used for named parameters, rather than getting named paramete= rs by a very restricted use of designated initializers.

It feels les= s like a hack that way.

The problem with= adding designated initializers alone is that they enhance aggregates but n= ot classes with constructors. This impedes refactoring an aggregate into a = non-aggregate, which is a very common operation.

That is something of a danger, yes. But I would rather find a way to= mitigate that problem than to deliberately gimp the functionality.<= br>
Here's a possible solution:

If the initializer list conta= ins designated initializers, then it will attempt to use aggregate initiali= zation on the target object type. If the target object is not an aggregate,= then it will check all of the constructors for the target. If it finds a c= onstructor that takes only one parameter (minus defaults of course) which <= i>is an aggregate, then it will initialize an aggregate and pass it to = that constructor.

You could even recursively apply those rules. If a= constructor takes one argument that has a constructor that takes one argum= ent that has a constructor that takes one argument that is an aggregate, th= en the initializer list constructs that type, passes it to the next object,= then passes the result to the next, and so on.

That way, when you r= efactor an aggregate into a non-aggregate, all you need to do is create a t= hrowaway aggregate that matches the old aggregate, which your now-non-aggre= gate type uses for named parameter object initialization.

Thus, a= ny non-aggregate could be initialized like this:

non_aggregate nagg <= span style=3D"color: #660;" class=3D"styled-by-prettify">=3D {.param1 =3D 20, <= /span>.param3 =3D 50};

Yeah, this su= ggestion effectively uses brace elision, which I despise. But it does solve= the problem, and it gives us nice functionality that your more limited app= roach would not have provided.

--

---
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_7377_1367054356.1440079031472-- ------=_Part_7376_339109379.1440079031471-- .