220 19935 article Path: news.gmane.org!not-for-mail From: "Arthur O'Dwyer" Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: default arguments Date: Wed, 19 Aug 2015 16:53:11 -0700 Lines: 400 Approved: news@gmane.org Message-ID: References: <89bf9d09-00ed-45db-bf88-39c844707bd1@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=e89a8f647a39c5acd3051db2bc9d X-Trace: ger.gmane.org 1440028414 5482 80.91.229.3 (19 Aug 2015 23:53:34 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 19 Aug 2015 23:53:34 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDLZJYWNDQIORLOUVYCRUBHD2CGHC@isocpp.org Thu Aug 20 01:53:23 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-pa0-f71.google.com ([209.85.220.71]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZSDAQ-0008Fl-H0 for gclcip-std-proposals@m.gmane.org; Thu, 20 Aug 2015 01:53:14 +0200 Original-Received: by paom9 with SMTP id m9sf37651428pao.3 for ; Wed, 19 Aug 2015 16:53:13 -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: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=NO3ZbQvHKApE/NIW9z/b033qbgYNkI0CmGebYiguTnE=; b=QI1mqLZa8PiL0BUNVYd3jRcz8RZ8geBUsSyKnNJxtjXkw+TnzbsOULvCrFmYXd7yNA 8acFGjUUSiblMZUGyjpiIGa9eABxY9+vpREJwXecAGBDWL6/zVZkGlBc9VK8OxBdHPP8 5ydYnWO8PxVyMPXXnIQBYufdsgqmtuOKSvKzoMigjA+QKrppvg3uNfrI2WhH3dKDnyYL /Ruexib1d1QrY/0X7XqWjoVnXH21PMHmcg9wrf1YOyDrlOZsE++0aXVnGC4NQ6qbk33Z uWK5pIDH9PPpCNWfnWbW2Da+GRAkg+79ruBnaI6Qhnxuso53qr0gf/2Ca2FkdXh/pr3j v1kw== X-Gm-Message-State: ALoCoQl3f0G67QfgfshMI7pu8xqMovepgOoV+53Qs3f+50w6TMfYcrhqDaG7BsaVe9Ne140scQrA X-Received: by 10.68.65.103 with SMTP id w7mr129685pbs.3.1440028393267; Wed, 19 Aug 2015 16:53:13 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.182.78.106 with SMTP id a10ls154406obx.43.gmail; Wed, 19 Aug 2015 16:53:12 -0700 (PDT) X-Received: by 10.60.178.212 with SMTP id da20mr163344oec.70.1440028392334; Wed, 19 Aug 2015 16:53:12 -0700 (PDT) Original-Received: from mail-ob0-x22d.google.com (mail-ob0-x22d.google.com. [2607:f8b0:4003:c01::22d]) by mx.google.com with ESMTPS id 194si1723639oif.69.2015.08.19.16.53.12 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 19 Aug 2015 16:53:12 -0700 (PDT) Received-SPF: pass (google.com: domain of arthur.j.odwyer@gmail.com designates 2607:f8b0:4003:c01::22d as permitted sender) client-ip=2607:f8b0:4003:c01::22d; Original-Received: by obbwr7 with SMTP id wr7so18605326obb.2 for ; Wed, 19 Aug 2015 16:53:12 -0700 (PDT) X-Received: by 10.182.107.233 with SMTP id hf9mr18073obb.35.1440028392006; Wed, 19 Aug 2015 16:53:12 -0700 (PDT) Original-Received: by 10.60.35.137 with HTTP; Wed, 19 Aug 2015 16:53:11 -0700 (PDT) In-Reply-To: X-Original-Sender: arthur.j.odwyer@gmail.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of arthur.j.odwyer@gmail.com designates 2607:f8b0:4003:c01::22d as permitted sender) smtp.mailfrom=arthur.j.odwyer@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:19935 Archived-At: --e89a8f647a39c5acd3051db2bc9d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On the subject of C and named parameters, I'll add that Ben Klemens' "21st Century C" shows 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... struct MyFunc_parameters { int buffer_size; int timeout; int tries; }; #define MyFunc(...) MyFunc_((struct MyFunc_parameters){ .buffer_size=3D1024= , ..timeout=3D5, .tries=3D3, ##__VA_ARGS__ }) void MyFunc_(struct MyFunc_parameters p) { for (int i=3D0; i < p.tries; ++i) { allocate(p.buffer_size); if (time() > p.timeout) bail(); } } int main() { MyFunc(); MyFunc(.buffer_size =3D 2048); MyFunc(.timeout =3D 10); MyFunc(.tries =3D 5, .buffer_size =3D 2048); } (I don't think the book is suggesting that every function in every C program ought to use this idiom, any more than every Python function ought to use **kwargs. It's just a nice technique for building user-friendly C99 APIs.) This uses a whole bunch of C99-specific features; it's unlikely that C++ will *ever* get *all* of the necessary features. But it shows that you don't need specific language-level support for defaulted parameters in order to achieve Pythonesque syntax =E2=80=94 and in fact a syntax *nicer* = than C++98's defaulted parameters! (Because the caller doesn't need to care about the order in which the callee declared its arguments; and because it's obvious to the callee that the "parameters"' names are part of the API.) =E2=80=93Arthur On Wed, Aug 19, 2015 at 10:50 AM, David Rodr=C3=ADguez Ibeas wrote: > How does that violate an encapsulation that does not exist? All members > are public in the struct=E2=80=A6 you might dislike it on different accou= nts but > encapsulation is not an issue with that code. Other pro=C2=B4s, the argu= ments > are named, which is stable across refactors that might shift the position= s > (assuming sensible names, the caller wants the 'a' to have value X or the > 'b' to have value Z. Depending on the position of the member in the struc= t > (and passing 'default' if needed for the previous arguments) is *more* > coupled, not less coupled. > > For initialization of structs, the C way is clearly better than the C++ > way here. A different question is whether we want to put some effort into > that part of the language when we can assume that most types are not > all-members-public. > > Then again this is only related to default arguments to functions in that > uniform initialization would be even less uniform in certain cases. I do > see the problems with named arguments, I still think that to be the bette= r > way. Whether initialization of structs can be made compatible with C once > again=E2=80=A6 would be nice here, but I imagine not that many people car= e. > > David > > On Wed, Aug 19, 2015 at 5:27 PM, Arthur Tchaikovsky > wrote: > >> It *is not* simpler. What you've just shown is a violation of >> encapsulation. Not simplification. >> >> >> On Wednesday, 19 August 2015 16:08:52 UTC+1, S.B. wrote: >>> >>> It's even simpler if we could write >>> >>> struct s { >>> int a =3D 1337; >>> int b =3D 4096; >>> }; >>> >>> int main() { >>> s x; >>> s y { 42 }; // or s y { .a =3D 42 }; >>> s z { .b =3D 42 }; >>> return 0; >>> } >>> >>> :) >>> >>> On Wednesday, August 19, 2015 at 2:02:01 PM UTC+8, Max Truxa wrote: >>>> >>>> I have to agree with Matt Calabrese completely. As it was already >>>> asserted named arguments are not going to happen anytime soon (if at a= ll). >>>> >>>> Earlier in this thread there were workarounds listed which are more or >>>> less comparable to the proposal in their effect. >>>> I would like to elaborate some more on one of these workarounds, as it >>>> can be mapped pretty much 1-to-1 to the proposal and it happens to be = the >>>> solution I employ when encountering this kind of problem. >>>> >>>> >>>> # Current workaround. >>>> >>>> struct s { >>>> static int const default_a =3D 1337; >>>> static int const default_b =3D 4096; >>>> s(int a =3D default_a, int b =3D default_b) >>>> : a(a), b(b) { } >>>> int a; >>>> int b; >>>> }; >>>> >>>> int main() { >>>> s x; >>>> s y(42); >>>> s z(s::default_a, 42); >>>> return 0; >>>> } >>>> >>>> See working code here: http://ideone.com/OKtbuc >>>> >>>> >>>> # Using the proposed syntax. >>>> >>>> struct s { >>>> s(int a =3D 1337, int b =3D 4096) >>>> : a(a), b(b) { } >>>> int a; >>>> int b; >>>> }; >>>> >>>> int main() { >>>> s x; >>>> s y(42); >>>> s z(default, 42); >>>> return 0; >>>> } >>>> >>>> The current solution has a number of drawbacks. >>>> 1) It's unnecessarily verbose. >>>> 2) It's easy to mess up for parameters that have the same type. (`s >>>> z(s::default_b, 42)` - Oops, passed `default_b` as `a`.) >>>> 3) When looking up the actual default values there is one more hop to >>>> make. It's not sufficient to look at the function declaration but >>>> additionally we have to look for e.g. default_a. >>>> >>>> -- >> >> --- >> You received this message because you are subscribed to the Google Group= s >> "ISO C++ Standard - Future Proposals" group. >> To unsubscribe from this group and stop receiving emails from it, send a= n >> 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/. >> > > -- > > --- > You received this message because you are subscribed to a topic in the > Google Groups "ISO C++ Standard - Future Proposals" group. > To unsubscribe from this topic, visit > https://groups.google.com/a/isocpp.org/d/topic/std-proposals/3iegpTsMuT0/= unsubscribe > . > To unsubscribe from this group and all its topics, 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/. > --=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/. --e89a8f647a39c5acd3051db2bc9d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On the subject of C and named parameters, I'll add tha= t Ben Klemens&= #39; "21st Century C" shows a very nice idiom for getting Pyt= hon-style named parameters out of a C99 compiler. I'm paraphrasing from= memory a bit in the code sample below...

struct MyFunc_parameters {
=C2=A0 int buffer_size;
=C2=A0 int timeout;
=C2=A0 int tries;
};
#define MyFunc(...) MyFunc_((struct MyFunc_parameters){ .buffer_size=3D102= 4, .timeout=3D5, .tries=3D3, ##__VA_ARGS__ })
void MyFunc_(struct MyFunc_parameters p) {=
=C2=A0 for (int i=3D0; i <= ; p.tries; ++i) {
=C2= =A0 =C2=A0 allocate(p.buffer_size);
=C2=A0 =C2=A0 if (time() > p.timeout) bail();
=
=C2=A0 }
}

int m= ain() {
=C2=A0 MyFunc(= );
=C2=A0 MyFunc(.buff= er_size =3D 2048);
=C2= =A0 MyFunc(.timeout =3D 10);
=C2=A0 MyFunc(.tries =3D 5, .buffer_size =3D 2048);
}

(I d= on't think the book is suggesting that every function in every C progra= m ought to use this idiom, any more than every Python function ought to use= **kwargs. It's just a nice = technique for building user-friendly C99 APIs.)

Th= is uses a whole bunch of C99-specific features; it's unlikely that C++ = will ever get all of the necessary features. But it shows tha= t you don't need specific language-level support for defaulted paramete= rs in order to achieve Pythonesque syntax =E2=80=94 and in fact a syntax nicer than C++98's defaulted parameters! (Because the caller doesn= 't need to care about the order in which the callee declared its argume= nts; and because it's obvious to the callee that the "parameters&q= uot;' names are part of the API.)

=E2=80=93Art= hur


On Wed, Aug 19, 2015 at 10:50 AM, David Rodr=C3= =ADguez Ibeas <dibeas@ieee.org> wrote:
How does that violate an encapsulation that doe= s not exist? All members are public in the struct=E2=80=A6 you might dislik= e it on different accounts but encapsulation is not an issue with that code= ..=C2=A0 Other pro=C2=B4s, the arguments are named, which is stable across r= efactors that might shift the positions (assuming sensible names, the calle= r wants the 'a' to have value X or the 'b' to have value Z.= Depending on the position of the member in the struct (and passing 'de= fault' if needed for the previous arguments) is *more* coupled, not les= s coupled.

For initialization of structs, the C way is c= learly better than the C++ way here. A different question is whether we wan= t to put some effort into that part of the language when we can assume that= most types are not all-members-public.=C2=A0

Then= again this is only related to default arguments to functions in that unifo= rm initialization would be even less uniform in certain cases.=C2=A0 I do s= ee the problems with named arguments, I still think that to be the better w= ay. Whether initialization of structs can be made compatible with C once ag= ain=E2=80=A6 would be nice here, but I imagine not that many people care.

=C2=A0 =C2=A0 =C2=A0David

On Wed, Aug 19, 2015 at 5:27 PM= , Arthur Tchaikovsky <atch.cpp@gmail.com> wrote:
It *is not* simpler. What you'= ve just shown is a violation of encapsulation. Not simplification.


On Wednesday, 19 August 2015 16:08:52 UTC+1, S.B. wrote:
It's even simpler if we= could write

struct s {
=C2=A0 =C2=A0 int a =3D 1337;
=C2=A0 =C2=A0 int b =3D <= span style=3D"color:#066">4096;
};
=C2=A0
int<= /span> main()<= /span> {
=C2=A0 =C2=A0 s x;
=C2=A0 =C2=A0 s y { 42 }; // or s y { .a =3D 42 };
= =C2=A0 =C2=A0 s z { .b =3D 42 };=C2=A0 =C2=A0 return 0;
}

:)

On Wednesday, August 19, = 2015 at 2:02:01 PM UTC+8, Max Truxa wrote:
I have to agree with Matt Calabrese completely. As it was already as= serted named arguments are not going to happen anytime soon (if at all).

= Earlier in this thread there were workarounds listed which are more or less= comparable to the proposal in their effect.
I would like to elaborate s= ome more on one of these workarounds, as it can be mapped pretty much 1-to-= 1 to the proposal and it happens to be the solution I employ when encounter= ing this kind of problem.


# Current workaround.

struct s {<= br>=C2=A0 =C2=A0 static int const default_a =3D 1337;
=C2=A0 =C2=A0 stat= ic int const default_b =3D 4096;
=C2=A0 =C2=A0 s(int a =3D default_a, in= t b =3D default_b)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 : a(a), b(b) { }
=C2= =A0 =C2=A0 int a;
=C2=A0 =C2=A0 int b;
};
=C2=A0
int main() {=C2=A0 =C2=A0 s x;
=C2=A0 =C2=A0 s y(42);
=C2=A0 =C2=A0 s z(s::defa= ult_a, 42);
=C2=A0 =C2=A0 return 0;
}

See working code here: http:= //ideone.com/OKtbuc


# Using the proposed syntax.

struct= s {
=C2=A0 =C2=A0 s(int a =3D 1337, int b =3D 4096)
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 : a(a), b(b) { }
=C2=A0 =C2=A0 int a;
=C2=A0 =C2=A0 int= b;
};
=C2=A0
int main() {
=C2=A0 =C2=A0 s x;
=C2=A0 =C2=A0 = s y(42);
=C2=A0 =C2=A0 s z(default, 42);
=C2=A0 =C2=A0 return 0;
}=

The current solution has a number of drawbacks.
1) It's unnec= essarily verbose.
2) It's easy to mess up for parameters that have t= he same type. (`s z(s::default_b, 42)` - Oops, passed `default_b` as `a`.)<= br>3) When looking up the actual default values there is one more hop to ma= ke. It's not sufficient to look at the function declaration but additio= nally we have to look for e.g. default_a.

--

---
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-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/gro= up/std-proposals/.

--

---
You received this message because you are subscribed to a topic in the Goog= le Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this topic, visit https://groups.google.com/a/isocpp.org/d/topic/std-proposals/3iegpTsMuT0= /unsubscribe.
To unsubscribe from this group and all its topics, send an email to std-prop= osals+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/gro= up/std-proposals/.

--

---
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>.
--e89a8f647a39c5acd3051db2bc9d-- .