220 19884 article Path: news.gmane.org!not-for-mail From: =?UTF-8?Q?David_Rodr=C3=ADguez_Ibeas?= Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: default arguments Date: Tue, 18 Aug 2015 11:22:27 +0100 Lines: 165 Approved: news@gmane.org Message-ID: References: Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=089e0111d0c8812933051d934b4b X-Trace: ger.gmane.org 1439893352 16318 80.91.229.3 (18 Aug 2015 10:22:32 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 18 Aug 2015 10:22:32 +0000 (UTC) To: "std-proposals@isocpp.org" Original-X-From: std-proposals+bncBDIIVO6GQULBBZEOZSXAKGQE4CVVIVY@isocpp.org Tue Aug 18 12:22:30 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-qk0-f197.google.com ([209.85.220.197]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZRe2H-0002vP-OO for gclcip-std-proposals@m.gmane.org; Tue, 18 Aug 2015 12:22:29 +0200 Original-Received: by qkfn3 with SMTP id n3sf234270985qkf.3 for ; Tue, 18 Aug 2015 03:22:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:content-type: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=W9h5RBA8wbieZafW6ue3ENnRfw1LkfVvZFS7QhOmEYk=; b=MUzUxBIiwyFPPvbmXF+VgEvsh8PJND8l9EaX0+9LSw8IG1it4m1U2Y/j6p0M77gsMT 2hFpBwByJ0+DvXBYDg3Akl+AQJQdp4tPM2r3To4S9Gm2vE1R+OFz1EW3Mul/NIXVJLuj GyyYSJ3Qu9ZS7Rzo9zSomoB8s571QoqhwRGZV+/9B7Y9BAUBbFcAGRIiLLfHUGMbO4MH BYOpUFUbvweKpq2t2uEhjVtTClMknBbXwOJC8EWV52BzP6OP/lua/MHcWsl3c5ZZaj6l k+3rZ8bSi2ot9Vb3/XMKA9pk0tcUsjgL1K0tfK1EslgJyILPozbxKvYmAYmBRBFpZONi jAfg== X-Gm-Message-State: ALoCoQk0njmllPjvS2djZ5fk7hr7bmN9I9VHvdXS6Qm3ojkrJhbqKzzNrUhrkBfWKDh3Tosnervg X-Received: by 10.140.239.21 with SMTP id k21mr5213556qhc.14.1439893349030; Tue, 18 Aug 2015 03:22:29 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.50.62.106 with SMTP id x10ls342551igr.23.gmail; Tue, 18 Aug 2015 03:22:28 -0700 (PDT) X-Received: by 10.107.40.85 with SMTP id o82mr5928717ioo.83.1439893348101; Tue, 18 Aug 2015 03:22:28 -0700 (PDT) Original-Received: from mail-ig0-x22b.google.com (mail-ig0-x22b.google.com. [2607:f8b0:4001:c05::22b]) by mx.google.com with ESMTPS id kc5si9439341igb.30.2015.08.18.03.22.28 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 18 Aug 2015 03:22:28 -0700 (PDT) Received-SPF: pass (google.com: domain of dribeas@gmail.com designates 2607:f8b0:4001:c05::22b as permitted sender) client-ip=2607:f8b0:4001:c05::22b; Original-Received: by igui7 with SMTP id i7so76129063igu.0 for ; Tue, 18 Aug 2015 03:22:28 -0700 (PDT) X-Received: by 10.50.124.4 with SMTP id me4mr22090081igb.34.1439893347705; Tue, 18 Aug 2015 03:22:27 -0700 (PDT) Original-Sender: dribeas@gmail.com Original-Received: by 10.107.192.131 with HTTP; Tue, 18 Aug 2015 03:22:27 -0700 (PDT) In-Reply-To: X-Original-Sender: dibeas@ieee.org X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of dribeas@gmail.com designates 2607:f8b0:4001:c05::22b as permitted sender) smtp.mailfrom=dribeas@gmail.com; dkim=pass header.i=@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:19884 Archived-At: --089e0111d0c8812933051d934b4b Content-Type: text/plain; charset=UTF-8 On Tue, Aug 18, 2015 at 10:42 AM, Arthur Tchaikovsky wrote: > That genuinely seems pointless/silly to me, unless you can provide some > convincing use cases. > On Tuesday, 18 August 2015 10:34:39 UTC+1, Johannes Schaub wrote: >> >> I would also wanna solve this with named arguments >> >> f(.b = 2, .d = 4) >> >> And index based >> >> f([1] = 2, [3] = 4) >> >> >> Any use case in which you may end up using 'default' in your proposal is a use case for these two approaches. In the first case, it lets you focus on what parameters are being configured (rather than defaulted) without having to look at the function declaration, 'f(.b = 2, .d = 4)' is equivalent to 'f(default, 2, default, 4)' and I find the former easier to read. Using indices is something that I had not considered before in the context of a regular function call, but I can imagine how 'f([3] = 4)' might be more readable than 'f(default, default, default, 4)' on two accounts: more concise and the counting is done for you. Now, going back from the high level desire to the implementability and potential issues, these two are allowed as initializers for structs in C (which is probably where Johannes is comming from), and while the former ('f(.b = 2)') is kind of clean the latter does lead to surprises for inexperienced programmers: int a[10] = { [3] = 1, [2] = 5, 6 }; // what values are in the array? Still, that might be easier than implementing named arguments. The "named" arguments work nicely with a 'struct' since the type can be defined only once, but it leads to different sorts of confusion for functions that may have multiple declarations: void f(int a = 1, int b = 2); void f(int b = 1, int a = 2); // redeclaration f( .a = 5 ); // f(5, 2)? f(1, 5)? Which AFAIK is one of the issues that this form of proposals have faced in the past. I recall also some discussions in this forum (or maybe even papers?) aiming for a syntax that would allow this by enabling warning/errors when a redeclaration used different names than the original declaration but I did not see any of those prosper. BTW, forcing the same name in redeclarations is part of what our internal coding guidelines mandate and we have tools for verification, not sure about other shops. Personally I have shifted from liking default arguments to trying to avoid them if at all possible as they complicate changes in old code (add a new non-defaulted argument and if unlucky users passing all arguments explicitly will not fail to compile but do something different than they intended). Overall, I find that if a nice clean solution could be reached, it would benefit the language, on those lines, I'd rather go into solutions that allow tagging a function as "names are important" (maybe a function attribute), having the compiler enforce that redeclarations use the same names for functions tagged as such [optionally allow a name to be dropped, but not changed, for implementations that might not use some of the arguments] and then using named arguments in the call seems cleaner than having to count the number of 'default'. On the other hand, this proposal is much easier to get into the language. David -- --- 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 email 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-proposals/. --089e0111d0c8812933051d934b4b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Aug 18, 2015 at 10:42 AM, Arthur Tchaikovsky <atch.cpp@gmail.com&= gt; wrote:
That g= enuinely seems pointless/silly to me, unless you can provide some convincin= g use cases.

On Tuesday, 18 August 2015 10:34:39 UTC+1, Johannes = Schaub wrote:

I would also wanna solve this with named arguments

=C2=A0 f(.b =3D 2, .d =3D 4)

And index based

=C2=A0 f([1] =3D 2, [3] =3D 4)



Any = use case in which you may end up using 'default' in your proposal i= s a use case for these two approaches.=C2=A0 In the first case, it lets you= focus on what parameters are being configured (rather than defaulted) with= out having to look at the function declaration, 'f(.b =3D 2, .d =3D 4)&= #39; is equivalent to 'f(default, 2, default, 4)' and I find the fo= rmer easier to read.

Using indices is something that I had not consi= dered before in the context of a regular function call, but I can imagine h= ow 'f([3] =3D 4)' might be more readable than 'f(default, defau= lt, default, 4)' on two accounts: more concise and the counting is done= for you.

Now, going back from the high level desire to the implemen= tability and potential issues, these two are allowed as initializers for st= ructs in C (which is probably where Johannes is comming from), and while th= e former ('f(.b =3D 2)') is kind of clean the latter does lead to s= urprises for inexperienced programmers:

int a[10] =3D { [3] =3D 1, [= 2] =3D 5, 6 }; // what values are in the array?

Still, that might be= easier than implementing named arguments.=C2=A0 The "named" argu= ments work nicely with a 'struct' since the type can be defined onl= y once, but it leads to different sorts of confusion for functions that may= have multiple declarations:

void f(int a =3D 1, int b =3D 2);
vo= id f(int b =3D 1, int a =3D 2); =C2=A0// redeclaration

f( .a =3D 5 )= ; // f(5, 2)? f(1, 5)?=C2=A0

Which AFAIK is one of the issues that t= his form of proposals have faced in the past.=C2=A0 I recall also some disc= ussions in this forum (or maybe even papers?) aiming for a syntax that woul= d allow this by enabling warning/errors when a redeclaration used different= names than the original declaration but I did not see any of those prosper= .. BTW, forcing the same name in redeclarations is part of what our internal= coding guidelines mandate and we have tools for verification, not sure abo= ut other shops.

Personally I have shifted from liking default= arguments to trying to avoid them if at all possible as they complicate ch= anges in old code (add a new non-defaulted argument and if unlucky users pa= ssing all arguments explicitly will not fail to compile but do something di= fferent than they intended).

Overall, I find that if a nice clean so= lution could be reached, it would benefit the language, on those lines, I&#= 39;d rather go into solutions that allow tagging a function as "names = are important" (maybe a function attribute), having the compiler enfor= ce that redeclarations use the same names for functions tagged as such [opt= ionally allow a name to be dropped, but not changed, for implementations th= at might not use some of the arguments] and then using named arguments in t= he call seems cleaner than having to count the number of 'default'.= On the other hand, this proposal is much easier to get into the language.<= br>
=C2=A0 =C2=A0 David

--

---
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>.
--089e0111d0c8812933051d934b4b-- .