220 19895 <7066b166-9472-4ad6-ac3c-2db527ed7818@isocpp.org> article
Path: news.gmane.org!not-for-mail
From: Arthur Tchaikovsky <atch.cpp@gmail.com>
Newsgroups: gmane.comp.lang.c++.isocpp.proposals
Subject: Re: default arguments
Date: Tue, 18 Aug 2015 09:37:54 -0700 (PDT)
Lines: 235
Approved: news@gmane.org
Message-ID: <7066b166-9472-4ad6-ac3c-2db527ed7818@isocpp.org>
References: <ef9c7cbe-e8f1-4196-83bc-11a1c9b2798c@isocpp.org>	<CANu6V4UOxgZ9GV9f8DTbtW6BXrBPA7_2yUDRyhXv5BptvybHFA@mail.gmail.com>	<ab64c760-eeca-426a-953f-99d7a19919f6@isocpp.org> <CAD6_Qj_SkX1r_Egr0FHgk21ASVQuDkYrn1Cy7+dRAJFwHpG72w@mail.gmail.com>
 <mqvdv7$6tc$1@ger.gmane.org>
Reply-To: std-proposals@isocpp.org
NNTP-Posting-Host: plane.gmane.org
Mime-Version: 1.0
Content-Type: multipart/mixed; 
	boundary="----=_Part_438_480074727.1439915875035"
X-Trace: ger.gmane.org 1439915880 3487 80.91.229.3 (18 Aug 2015 16:38:00 GMT)
X-Complaints-To: usenet@ger.gmane.org
NNTP-Posting-Date: Tue, 18 Aug 2015 16:38:00 +0000 (UTC)
Cc: mwoehlke.floss@gmail.com
To: ISO C++ Standard - Future Proposals <std-proposals@isocpp.org>
Original-X-From: std-proposals+bncBDL6FI4NYYERBZF6ZWXAKGQELC4I7MY@isocpp.org Tue Aug 18 18:37:59 2015
Return-path: <std-proposals+bncBDL6FI4NYYERBZF6ZWXAKGQELC4I7MY@isocpp.org>
Envelope-to: gclcip-std-proposals@m.gmane.org
Original-Received: from mail-qg0-f69.google.com ([209.85.192.69])
	by plane.gmane.org with esmtp (Exim 4.69)
	(envelope-from <std-proposals+bncBDL6FI4NYYERBZF6ZWXAKGQELC4I7MY@isocpp.org>)
	id 1ZRjte-0001Qy-3s
	for gclcip-std-proposals@m.gmane.org; Tue, 18 Aug 2015 18:37:58 +0200
Original-Received: by qgj62 with SMTP id 62sf185320338qgj.3
        for <gclcip-std-proposals@m.gmane.org>; Tue, 18 Aug 2015 09:37:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20120113;
        h=date:from:to:cc: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=2YGWsPSbevCMJANtgyZfWeMUfiWbdnUp+WzzFGflXi4=;
        b=c+qR5DV9wcDg2TNRB5L6ywg2UMVh5XFF7Z0eAgseQmVsW5lolz3T7pkH8ZtwYECFlw
         DoGi753MjQKcfUsupaYutVLSV/af4Ou85CrH9J372jI0ytKskBDoxeI8gaS55H58WXwa
         qiMou4/WfifX7S8xIQ65p/Ityeq+XSPdsNalKDGlfhYBYCMZxw0fda4xd3QRCXN7tr7q
         FWVmXWhMpePyJUE2jUZBUO2e1naHkJ+wZhJU8nf8Y8zzhx82KZlAd59rBW22sVq3b6cV
         AvvtVxq/2Lw4u3ftSWQhtuJRr55pnBmBULyTUjOwThASKGP9Ob4SyvcvKpEsdJI0hnCT
         D0ig==
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:cc: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=2YGWsPSbevCMJANtgyZfWeMUfiWbdnUp+WzzFGflXi4=;
        b=LnLzG5m1Mq8o4+KSL6lP7VWPQLrOYgGW/4zkLYjgyb8pwtgiVEb0hzx0orFXgn2/65
         ab/2NSid0yJVTX2yOBHd6ob6MNaCpt6EuOmX/xprB0XtYi2esmVD4HKTnAvkNhRY4P9N
         CI/AJ85N5KLsQN7cFlk09O4PyRNbMqj89zZgTnd5U0fXIo5AtiTUWOD7hHFi/eVRn81i
         0x53wtuzfXKT+LmZ7NyXG+4Vi8CA5w7wRtiHRE+YvKrGy6YIVAhskCsQF/zJDY1GJl8E
         +BXN3M/bD3nT7np7r0FQSTHfNLEKhhHvnCQWJitYgbaTM/eGHx15HLdjlqKncEqD5HSk
         CmzQ==
X-Gm-Message-State: ALoCoQmArEDKy1qdwFYJbONuJzxBghOU/+kMlTvhyCpuc6T/E6RmQQFlWveyXteawqGmQqzCiuYw
X-Received: by 10.13.207.1 with SMTP id r1mr6863649ywd.53.1439915877113;
        Tue, 18 Aug 2015 09:37:57 -0700 (PDT)
X-BeenThere: std-proposals@isocpp.org
Original-Received: by 10.140.41.167 with SMTP id z36ls3376320qgz.29.gmail; Tue, 18 Aug
 2015 09:37:55 -0700 (PDT)
X-Received: by 10.140.36.170 with SMTP id p39mr103729qgp.28.1439915875770;
        Tue, 18 Aug 2015 09:37:55 -0700 (PDT)
In-Reply-To: <mqvdv7$6tc$1@ger.gmane.org>
X-Original-Sender: atch.cpp@gmail.com
Precedence: list
Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org
List-ID: <std-proposals.isocpp.org>
X-Spam-Checked-In-Group: std-proposals@isocpp.org
X-Google-Group-Id: 399137483710
List-Post: <http://groups.google.com/a/isocpp.org/group/std-proposals/post>, <mailto:std-proposals@isocpp.org>
List-Help: <http://support.google.com/a/isocpp.org/bin/topic.py?topic=25838>, <mailto:std-proposals+help@isocpp.org>
List-Archive: <http://groups.google.com/a/isocpp.org/group/std-proposals/>
List-Subscribe: <http://groups.google.com/a/isocpp.org/group/std-proposals/subscribe>,
 <mailto:std-proposals+subscribe@isocpp.org>
List-Unsubscribe: <mailto:googlegroups-manage+399137483710+unsubscribe@googlegroups.com>,
 <http://groups.google.com/a/isocpp.org/group/std-proposals/subscribe>
Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:19895
Archived-At: <http://permalink.gmane.org/gmane.comp.lang.c++.isocpp.proposals/19895>

------=_Part_438_480074727.1439915875035
Content-Type: multipart/alternative; 
	boundary="----=_Part_439_656562220.1439915875035"

------=_Part_439_656562220.1439915875035
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I dear to disagree with the statement that the following example is self=20
documenting and easier to read:
auto c3ptr =3D new C{.timeout =3D 1};=20
How is this^^^ easier to read? And how is this self documenting? Only on=20
surface it seems that it is, both, but when you really think about it it is=
=20
neither self documenting nor easy to read. Why? Because having only one=20
argument initialized in {}, that is .timeout, leaves us with question, is=
=20
that the only argument to that class, or are there any other? If so, are=20
those arguments inited by default? If so, how many? Etc.
Compared to this:
auto c3ptr =3D new C(default, 1); // use a shorter timeout=20
It is immediately obvious how many arguments there are and which one of=20
them are default. And as for self documentation?
auto c3ptr =3D new C(default, /*timeout*/1); // use a shorter timeout=20


On Tuesday, 18 August 2015 15:03:38 UTC+1, Matthew Woehlke wrote:
>
> On 2015-08-18 06:22, David Rodr=C3=ADguez Ibeas wrote:=20
> > On Tue, Aug 18, 2015 at 10:42 AM, Arthur Tchaikovsky wrote:=20
> >> On Tuesday, 18 August 2015 10:34:39 UTC+1, Johannes Schaub wrote:=20
> >>> I would also wanna solve this with named arguments=20
> >>>=20
> >>>   f(.b =3D 2, .d =3D 4)=20
> >>=20
> >> That genuinely seems pointless/silly to me, unless you can provide som=
e=20
> >> convincing use cases.=20
> >=20
> > Any use case in which you may end up using 'default' in your proposal i=
s=20
> a=20
> > use case for these two approaches.  In the first case, it lets you focu=
s=20
> on=20
> > what parameters are being configured (rather than defaulted) without=20
> having=20
> > to look at the function declaration, 'f(.b =3D 2, .d =3D 4)' is equival=
ent=20
> to=20
> > 'f(default, 2, default, 4)' and I find the former easier to read.=20
>
> It's also self-documenting. Consider Arthur O'Dwyer's examples; which is=
=20
> easier to understand?=20
>
>   auto cptr =3D new C();         // usually the defaults are okay=20
>   auto c2ptr =3D new C(2048);    // use a bigger buffer=20
>   auto c3ptr =3D new C(default, 1); // use a shorter timeout=20
>
> - vs. -=20
>
>   auto cptr =3D new C{};=20
>   auto c2ptr =3D new C{.buffer =3D 2048};=20
>   auto c3ptr =3D new C{.timeout =3D 1};=20
>
> There's a reason named arguments are so popular in Python :-).=20
>
> > int a[10] =3D { [3] =3D 1, [2] =3D 5, 6 }; // what values are in the ar=
ray?=20
>
> This never happens because your example is ill-formed. Parameters that=20
> are neither named nor indexed must precede parameters that are. (In=20
> Python also, and for similar reasons.)=20
>
> > Still, that might be easier than implementing named arguments.  The=20
> "named"=20
> > arguments work nicely with a 'struct' since the type can be defined onl=
y=20
> > once, but it leads to different sorts of confusion for functions that=
=20
> may=20
> > have multiple declarations:=20
> >=20
> > void f(int a =3D 1, int b =3D 2);=20
> > void f(int b =3D 1, int a =3D 2);  // redeclaration=20
> >=20
> > Which AFAIK is one of the issues that this form of proposals have faced=
=20
> in=20
> > the past.  I recall also some discussions in this forum (or maybe even=
=20
> > papers?) aiming for a syntax that would allow this by enabling=20
> > warning/errors when a redeclaration used different names than the=20
> original=20
> > declaration but I did not see any of those prosper.=20
>
> Probably there should be a way of naming parameters that "codifies" the=
=20
> name, making it part of the ABI. And, yes, such redeclarations would be=
=20
> disallowed.=20
>
> --=20
> Matthew=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_439_656562220.1439915875035
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I dear to disagree with the statement that the following e=
xample is self documenting and easier to read:<br>auto c3ptr =3D new C{.tim=
eout =3D 1};
<br>How is this^^^ easier to read? And how is this self documenting? Only o=
n surface it seems that it is, both, but when you really think about it it =
is neither self documenting nor easy to read. Why? Because having only one =
argument initialized in {}, that is .timeout, leaves us with question, is t=
hat the only argument to that class, or are there any other? If so, are tho=
se arguments inited by default? If so, how many? Etc.<br>Compared to this:<=
br>auto c3ptr =3D new C(default, 1); // use a shorter timeout
<br>It is immediately obvious how many arguments there are and which one of=
 them are default. And as for self documentation?<br>auto c3ptr =3D new C(d=
efault, /*timeout*/1); // use a shorter timeout
<br><br><br>On Tuesday, 18 August 2015 15:03:38 UTC+1, Matthew Woehlke  wro=
te:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;=
border-left: 1px #ccc solid;padding-left: 1ex;">On 2015-08-18 06:22, David =
Rodr=C3=ADguez Ibeas wrote:
<br>&gt; On Tue, Aug 18, 2015 at 10:42 AM, Arthur Tchaikovsky wrote:
<br>&gt;&gt; On Tuesday, 18 August 2015 10:34:39 UTC+1, Johannes Schaub wro=
te:
<br>&gt;&gt;&gt; I would also wanna solve this with named arguments
<br>&gt;&gt;&gt;
<br>&gt;&gt;&gt; =C2=A0 f(.b =3D 2, .d =3D 4)
<br>&gt;&gt;
<br>&gt;&gt; That genuinely seems pointless/silly to me, unless you can pro=
vide some
<br>&gt;&gt; convincing use cases.
<br>&gt;
<br>&gt; Any use case in which you may end up using &#39;default&#39; in yo=
ur proposal is a
<br>&gt; use case for these two approaches. =C2=A0In the first case, it let=
s you focus on
<br>&gt; what parameters are being configured (rather than defaulted) witho=
ut having
<br>&gt; to look at the function declaration, &#39;f(.b =3D 2, .d =3D 4)&#3=
9; is equivalent to
<br>&gt; &#39;f(default, 2, default, 4)&#39; and I find the former easier t=
o read.
<br>
<br>It&#39;s also self-documenting. Consider Arthur O&#39;Dwyer&#39;s examp=
les; which is
<br>easier to understand?
<br>
<br>=C2=A0 auto cptr =3D new C(); =C2=A0 =C2=A0 =C2=A0 =C2=A0 // usually th=
e defaults are okay
<br>=C2=A0 auto c2ptr =3D new C(2048); =C2=A0 =C2=A0// use a bigger buffer
<br>=C2=A0 auto c3ptr =3D new C(default, 1); // use a shorter timeout
<br>
<br>- vs. -
<br>
<br>=C2=A0 auto cptr =3D new C{};
<br>=C2=A0 auto c2ptr =3D new C{.buffer =3D 2048};
<br>=C2=A0 auto c3ptr =3D new C{.timeout =3D 1};
<br>
<br>There&#39;s a reason named arguments are so popular in Python :-).
<br>
<br>&gt; int a[10] =3D { [3] =3D 1, [2] =3D 5, 6 }; // what values are in t=
he array?
<br>
<br>This never happens because your example is ill-formed. Parameters that
<br>are neither named nor indexed must precede parameters that are. (In
<br>Python also, and for similar reasons.)
<br>
<br>&gt; Still, that might be easier than implementing named arguments. =C2=
=A0The &quot;named&quot;
<br>&gt; arguments work nicely with a &#39;struct&#39; since the type can b=
e defined only
<br>&gt; once, but it leads to different sorts of confusion for functions t=
hat may
<br>&gt; have multiple declarations:
<br>&gt;=20
<br>&gt; void f(int a =3D 1, int b =3D 2);
<br>&gt; void f(int b =3D 1, int a =3D 2); =C2=A0// redeclaration
<br>&gt;=20
<br>&gt; Which AFAIK is one of the issues that this form of proposals have =
faced in
<br>&gt; the past. =C2=A0I recall also some discussions in this forum (or m=
aybe even
<br>&gt; papers?) aiming for a syntax that would allow this by enabling
<br>&gt; warning/errors when a redeclaration used different names than the =
original
<br>&gt; declaration but I did not see any of those prosper.
<br>
<br>Probably there should be a way of naming parameters that &quot;codifies=
&quot; the
<br>name, making it part of the ABI. And, yes, such redeclarations would be
<br>disallowed.
<br>
<br>--=20
<br>Matthew
<br>
<br></blockquote></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_439_656562220.1439915875035--
------=_Part_438_480074727.1439915875035--

.
