220 19945 article Path: news.gmane.org!not-for-mail From: David Krauss Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: default arguments Date: Fri, 21 Aug 2015 08:49:38 +0800 Lines: 182 Approved: news@gmane.org Message-ID: 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> <3a2aeb70-24c2-4a00-8c94-f6db5f3ca6b6@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_4C4F226E-788E-48CC-B289-7B288E6A70A2" X-Trace: ger.gmane.org 1440118198 14605 80.91.229.3 (21 Aug 2015 00:49:58 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 21 Aug 2015 00:49:58 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCW25A7E3QCRBLXL3GXAKGQEORQBYZQ@isocpp.org Fri Aug 21 02:49:53 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-oi0-f72.google.com ([209.85.218.72]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZSaWm-0001hJ-Fc for gclcip-std-proposals@m.gmane.org; Fri, 21 Aug 2015 02:49:52 +0200 Original-Received: by oifo84 with SMTP id o84sf77693034oif.3 for ; Thu, 20 Aug 2015 17:49:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-type:message-id:mime-version :subject:date:references:to:in-reply-to:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=xHstzMlp3ROpco2OgSJpCvt+KPSHezwA2y/elKQ12Ko=; b=UOls6AE/36SfRBzyRAmyyMw6Ze3hlTJQyn6QXIQdLYp3XhG+FmyycfRFzZho3W0LbY LUY8oXLvKfxpZ6Y82I+gBDIMSfMT0rpxx1NJaPAHpPq8OgaAqBvsjNAVRBhr4uwMKg2b l5sHVdrBjah1G1VxcyFRcgGCcYZPBmRtFYprX+BOMhiickuCK5YN2nK7lLFr6Lswk2Xi sHEAnPOs6A+sAWZlu5sa8Bcq2L3nVWQiq3lnlfBYxLZQRxqsa17kbboheARveu14URoL amYr9+J/YdsLZosSJ+C/tiKdR0hgEUrqlhSf+KvN22jSg1Fp+JO+AVBkf3yvs8Klbfj1 xCsg== X-Gm-Message-State: ALoCoQnG2cltT/nDB1i+NubTjvXkFfVnKQG4DDK1ODQbrKzXqVdoOWhu4F2D6ZFS7QLWpe7+7Zjj X-Received: by 10.182.18.69 with SMTP id u5mr4343094obd.39.1440118191241; Thu, 20 Aug 2015 17:49:51 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.50.141.161 with SMTP id rp1ls373472igb.21.canary; Thu, 20 Aug 2015 17:49:50 -0700 (PDT) X-Received: by 10.69.27.68 with SMTP id je4mr11574219pbd.163.1440118190263; Thu, 20 Aug 2015 17:49:50 -0700 (PDT) Original-Received: from mail-pa0-x229.google.com (mail-pa0-x229.google.com. [2607:f8b0:400e:c03::229]) by mx.google.com with ESMTPS id pr10si10023458pbb.122.2015.08.20.17.49.50 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 20 Aug 2015 17:49:50 -0700 (PDT) Received-SPF: pass (google.com: domain of potswa@gmail.com designates 2607:f8b0:400e:c03::229 as permitted sender) client-ip=2607:f8b0:400e:c03::229; Original-Received: by pacdd16 with SMTP id dd16so31107015pac.2 for ; Thu, 20 Aug 2015 17:49:50 -0700 (PDT) X-Received: by 10.68.65.77 with SMTP id v13mr11688585pbs.157.1440118189998; Thu, 20 Aug 2015 17:49:49 -0700 (PDT) Original-Received: from [172.20.10.2] ([121.54.54.182]) by smtp.gmail.com with ESMTPSA id ea4sm5633359pbc.48.2015.08.20.17.49.43 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 20 Aug 2015 17:49:46 -0700 (PDT) In-Reply-To: <3a2aeb70-24c2-4a00-8c94-f6db5f3ca6b6@isocpp.org> X-Mailer: Apple Mail (2.2098) X-Original-Sender: potswa@gmail.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of potswa@gmail.com designates 2607:f8b0:400e:c03::229 as permitted sender) smtp.mailfrom=potswa@gmail.com; dkim=pass header.i=@gmail.com; dmarc=pass (p=NONE dis=NONE) header.from=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:19945 Archived-At: --Apple-Mail=_4C4F226E-788E-48CC-B289-7B288E6A70A2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 > On 2015=E2=80=9308=E2=80=9320, at 9:57 PM, Nicol Bolas > wrote: >=20 > Thus, this proposal must include designated initializers for aggregates. Or wait for someone else to propose designated initializers. > And they specifically don=E2=80=99t apply under brace (uniform) initializ= ation. >=20 > I don't know which "they" you're referring to: designated initializers or= brace elision. =E2=80=9CThey=E2=80=9D are implicit braces. Designated initializers and bra= ce elision only work inside braces, and it should be obvious that I=E2=80= =99m not trying to throw away everything. > I'm going to assume that you mean to say that designated initializers sho= uld be restricted to function calls, without explicit braced-init-lists. If= that's not the case, then just ignore this section. The suggestion is that, given a workable proposal for designated initialize= rs (inside braced-init-lists) reflecting the implementation consensus, we s= olve the issue of providing designators to constructors and ordinary functi= ons (inside parens) by adding implicit braces immediately inside the parens= .. > I don't like the idea of hacking up a "solution" to named parameters this= way (admittedly, a solution that many other languages use). But I'd be muc= h happier with this if such a solution was just a natural outgrowth of a ge= nerally useful feature like designated aggregate initializers. My recollection is that there=E2=80=99s committee resistance to adding feat= ures to aggregates but not to constructors. I=E2=80=99ve not reviewed the m= inutes to verify this, but that=E2=80=99s the direction I=E2=80=99m coming = from. Personally, I also feel that designated initializers are already over= due for C++ standardization, but a broader proposal stands better chances b= y addressing such concerns. > Here's a possible solution: >=20 > If the initializer list contains designated initializers, then it will at= tempt to use aggregate initialization on the target object type. If the tar= get object is not an aggregate, then it will check all of the constructors = for the target. If it finds a constructor that takes only one parameter (mi= nus defaults of course) which is an aggregate, then it will initialize an a= ggregate and pass it to that constructor. This occurred to me too, but 1. It allows conversion to look just like direct-initialization. It require= s that a constructor call look like aggregate initialization, which I belie= ve should be discouraged. 2. It=E2=80=99s essentially a brace elision rule, and as you mentioned that= area is already complicated. Specifically, it=E2=80=99s a rule for omittin= g one outer level of braces, but the existing elision rule is based on desc= ending immediately to the innermost level. 3. It doesn=E2=80=99t address named function arguments, which is really the= more common request. > You could even recursively apply those rules. If a constructor takes one = argument that has a constructor that takes one argument that has a construc= tor that takes one argument that is an aggregate, then the initializer list= constructs that type, passes it to the next object, then passes the result= to the next, and so on. C++ doesn=E2=80=99t usually allow chained conversions. The programmer can e= asily generate a combinatorial explosion, if each potential step of the cha= in has multiple converting constructors. --=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/. --Apple-Mail=_4C4F226E-788E-48CC-B289-7B288E6A70A2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8
On 2015=E2= =80=9308=E2=80=9320, at 9:57 PM, Nicol Bolas <jmckesson@gmail.com> wrote:

Thus, this p= roposal must include designated initializers for aggregat= es.

<= /div>
Or wait for someone else to propose designated initial= izers.

And they specifically don=E2=80=99t = apply under brace (uniform) initialization.

I don't know which "they" you're referring to: desi= gnated initializers or brace elision.

=E2=80=9CThey=E2=80=9D are impli= cit braces. Designated initializers and brace elision on= ly work inside braces, and it should be obvious that I=E2=80=99m n= ot trying to throw away everything.

I'm going to assume that = you mean to say that designated initializers should be restricted to functi= on calls, without explicit braced-init-lists. If that's not the case, then = just ignore this section.

The suggestion is that, given a = workable proposal for designated initializers (inside braced-init-lists) re= flecting the implementation consensus, we solve the issue of providing desi= gnators to constructors and ordinary functions (inside parens) by adding im= plicit braces immediately inside the parens.

I don't like the= idea of hacking up a "solution" to named parameters this way (admittedly, = a solution that many other languages use). But I'd be much happier with thi= s if such a solution was just a natural outgrowth of a generally useful fea= ture like designated aggregate initializers.

My recollecti= on is that there=E2=80=99s committee resistance to adding features to aggre= gates but not to constructors. I=E2=80=99ve not reviewed the minutes to ver= ify this, but that=E2=80=99s the direction I=E2=80=99m coming from. Persona= lly, I also feel that designated initializers are already overdue for C++ s= tandardization, but a broader proposal stands better chances by addressing = such concerns.

Here's a possible solution:

If the initializer list contains designated initializers,= then it will attempt to use aggregate initialization on the target object = type. If the target object is not an aggregate, then it will check all of t= he constructors for the target. If it finds a constructor that takes only o= ne parameter (minus defaults of course) which is an aggre= gate, then it will initialize an aggregate and pass it to that constructor.=

This occurred to me too, but

1. It allows conversion to look just like dir= ect-initialization. It requires that a constructor call look like aggregate= initialization, which I believe should be discouraged.

2. It=E2=80=99s essentially a brace = elision rule, and as you mentioned that area is already complicated. Specif= ically, it=E2=80=99s a rule for omitting one outer level of braces, but the= existing elision rule is based on descending immediately to the innermost = level.

3. It does= n=E2=80=99t address named function arguments, which is really the more comm= on request.

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

C++ doesn= =E2=80=99t usually allow chained conversions. The programmer can easily gen= erate a combinatorial explosion, if each potential step of the chain has mu= ltiple converting constructors.

--

---
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>.
--Apple-Mail=_4C4F226E-788E-48CC-B289-7B288E6A70A2-- .