220 19938 <124ba022-8377-4ba3-be25-23e2134a9549@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: Wed, 19 Aug 2015 20:59:24 -0700 (PDT) Lines: 203 Approved: news@gmane.org Message-ID: <124ba022-8377-4ba3-be25-23e2134a9549@isocpp.org> References: <89bf9d09-00ed-45db-bf88-39c844707bd1@isocpp.org> <5F6E90B3-44BE-4A37-BE8F-91E1255E6407@gmail.com> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_4985_769217796.1440043164405" X-Trace: ger.gmane.org 1440043170 16821 80.91.229.3 (20 Aug 2015 03:59:30 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 20 Aug 2015 03:59:30 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCEKFTV6ZUMBBHNB2WXAKGQEIYXORWY@isocpp.org Thu Aug 20 05:59:29 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yk0-f199.google.com ([209.85.160.199]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZSH0i-0001Ai-Ki for gclcip-std-proposals@m.gmane.org; Thu, 20 Aug 2015 05:59:28 +0200 Original-Received: by ykbj6 with SMTP id j6sf27737607ykb.3 for ; Wed, 19 Aug 2015 20:59:27 -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=VE7R4l2VMx4XV1ebPgoREZEVXiiedeyvZRQnpbqtzjU=; b=mA0bR2Mdqzq3Fd/Z2ahqHPjsT18w0BhC5Jmf0V1lH9oArF6UbNQ7F2SJBYUs8SV7ba MPeJAvtMoA6ifSR1+f6I582ZZKsu2xUAVsm5g8tP43+6wGWSEHH3Xoffsc8plb4VjN+J Q4kB13lNUvsQPgGfHlfEDPTaW55U4WwaFbw1exne0tG0KXHN3IZF5dw8A5pyFOc5zkLn JD2Zn1jMlqV2wu97w/5p6AcIMHmQcEzNrpn92ubVZATgy1Dqbcee5K77hWkTK5pjRz1O OW7CcDmq2XGSMjb87HFuMroOIBu8knGVrUkArqR+arhpn8deRF/s2Fir9KV/FvJabvX3 MLeg== 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=VE7R4l2VMx4XV1ebPgoREZEVXiiedeyvZRQnpbqtzjU=; b=Q1pQIpzMAmTjQ2B8879y0RtSEUGBRHHoVO0fMDgAyQKiduoewQ1XC6H89c8GuSBHNT FsRuqppJcReDYVN/7fDytrNxKXF3jCFER7ZyGLd76emKfGs9AP7nARd69C9kEQeIrc7E cSX8bhcg6kkCZkgUXtfQpDmfLTZ5RLo8GwrIVf6adNUpvpHlugy+BmuOlSTfoZteDAY5 jtkoIpy2FXdwV+W9Zhy82Q3bjVzZlnA+rOLZNefWllqLs6qb8VNLbGZ5H9fue5GOC6If qewRwA/Fkuwpa7cwOMycLuZGn06+69Yd3yXZDIpkTWnFpv5mooqKH3E8G4UeDWB4h4Ib +bHQ== X-Gm-Message-State: ALoCoQll3l1l2dv66X7CWxjqFsz10+3hnODagXixohh2Pd/h+IvJI8XuUlBfjDzP7Ch9i5+OT7lu X-Received: by 10.129.146.5 with SMTP id j5mr729912ywg.36.1440043167656; Wed, 19 Aug 2015 20:59:27 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.140.41.167 with SMTP id z36ls460277qgz.29.gmail; Wed, 19 Aug 2015 20:59:25 -0700 (PDT) X-Received: by 10.140.99.44 with SMTP id p41mr7233qge.18.1440043165293; Wed, 19 Aug 2015 20:59:25 -0700 (PDT) In-Reply-To: <5F6E90B3-44BE-4A37-BE8F-91E1255E6407@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:19938 Archived-At: ------=_Part_4985_769217796.1440043164405 Content-Type: multipart/alternative; boundary="----=_Part_4986_330267063.1440043164405" ------=_Part_4986_330267063.1440043164405 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wednesday, August 19, 2015 at 9:59:08 PM UTC-4, David Krauss wrote: > > > On 2015=E2=80=9308=E2=80=9320, at 7:53 AM, Arthur O'Dwyer > wrote: > > On the subject of C and named parameters, I'll add that Ben Klemens'=20 > "21st Century C" shows= =20 > a very nice idiom for getting Python-style named parameters out of a C99= =20 > compiler. I'm paraphrasing from memory a bit in the code sample below=E2= =80=A6 > > > Perhaps the syntax of an *expression-list* beginning with =E2=80=9C.=E2= =80=9D should=20 > indicate implicit braces, added as sugar. I think that passing a struct i= s=20 > a superior design when lots of parameters are present, and one supported = by=20 > decades of experience. > Generally speaking, if you have that many parameters, then some of those=20 parameters almost certainly are pieces of larger semantic groupings. And=20 therefore they should have been grouped into structs to begin with. 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, it= =20 does lack the terrible syntactic noise of the C version, so it's already=20 ahead of the curve ;) The big downside I think has to do with the language. Your proposal makes= =20 sense, but not once you start providing default parameters. Here's an=20 example: parameters value{.buffer_size =3D 100, .timeout =3D 2, .tries =3D 3}; What does this do? I don't me from a top-level perspective; I'm not asking= =20 what you want it to mean. I'm asking what this actually does, in terms of= =20 the language? That braced-init-list *cannot* perform aggregate initialization, because=20 `parameters` is not an aggregate. Aggregates cannot have non-static data=20 member initializers. So what exactly are you proposing that this do? Do you intend to define a= =20 new class of pseudo-aggregate, which has all of the limitations of a=20 regular aggregate, only it allows NSDMIs? The problem with that is that NSDMI's operate by effectively modifying=20 constructors. They provide default parameters for a constructor's=20 initialization list; that's why they're not aggregates. If there are no=20 user-provided constructors, and you're not using the default constructor=20 (or one of the other special ones), it's not clear at all to me what code= =20 will be used to initialize the pseudo-aggregate. Where does the constructor= =20 you call get defined? Oh sure, we all know what we *want* to have happen. It's a matter of making= =20 it work in the language without breaking 20 other things. As for the implicit braces thing, that sounds like a very bad idea. Uniform= =20 initialization already has way too many implicit braces, to the point where= =20 it actually gets non-uniform. It's two extra characters; I don't see it as= =20 provoking that much syntactic noise. --=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_4986_330267063.1440043164405 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Wednesday, August 19, 2015 at 9:59:08 PM UTC-4, David Krauss wro= te:

On 2015=E2=80=9308=E2=80= =9320, at 7:53 AM, Arthur O'Dwyer <arthur....@gmail.com> wrote:<= /div>
On the subject of C and named param= eters, I'll add that=C2=A0Ben Klemens' "21st Century C"=C2= =A0shows a very nice idiom for getting Python-style named parameters= out of a C99 compiler. I'm paraphrasing from memory a bit in the code = sample below=E2=80=A6

Perhaps = the syntax of an=C2=A0expression-list=C2=A0beginning with =E2=80=9C<= font face=3D"Courier">.=E2=80=9D should indicate implicit braces, ad= ded as sugar.=C2=A0I think that passing a=C2=A0struc= t=C2=A0is a superior design when lots of parameters are present, and= one supported by decades of experience.

General= ly speaking, if you have that many parameters, then some of those parameter= s almost certainly are pieces of larger semantic groupings. And therefore t= hey should have been grouped into structs to begin with.

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

The big downside I think has to do with the language. Your= proposal makes sense, but not once you start providing default parameters.= Here's an example:

parameters value{.buffer_size =3D 100, .timeout =3D 2, .= tries =3D 3};

What = does this do? I don't me from a top-level perspective; I'm not aski= ng what you want it to mean. I'm asking what this actually does, in ter= ms of the language?

That braced-init-list cannot perform aggr= egate initialization, because `parameters` is not an aggregate. Aggregates = cannot have non-static data member initializers.

So what exactly are= you proposing that this do? Do you intend to define a new class of pseudo-= aggregate, which has all of the limitations of a regular aggregate, only it= allows NSDMIs?

The problem with that is that NSDMI's operate by= effectively modifying constructors. They provide default parameters for a = constructor's initialization list; that's why they're not aggre= gates. If there are no user-provided constructors, and you're not using= the default constructor (or one of the other special ones), it's not c= lear at all to me what code will be used to initialize the pseudo-aggregate= .. Where does the constructor you call get defined?

Oh sure, we all k= now what we want to have happen. It's a matter of making it work= in the language without breaking 20 other things.

As for the implic= it braces thing, that sounds like a very bad idea. Uniform initialization a= lready has way too many implicit braces, to the point where it actually get= s non-uniform. It's two extra characters; I don't see it as provoki= ng that much syntactic noise.

--

---
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_4986_330267063.1440043164405-- ------=_Part_4985_769217796.1440043164405-- .