220 19941 <2e02ced3-b0ec-4b83-b190-9acd809196a1@isocpp.org> article Path: news.gmane.org!not-for-mail From: Arthur Tchaikovsky Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: default arguments Date: Thu, 20 Aug 2015 02:11:43 -0700 (PDT) Lines: 412 Approved: news@gmane.org Message-ID: <2e02ced3-b0ec-4b83-b190-9acd809196a1@isocpp.org> References: <89bf9d09-00ed-45db-bf88-39c844707bd1@isocpp.org> <87b15f40-b36a-47bd-b822-8df53dd72287@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_133_1006987662.1440061903824" X-Trace: ger.gmane.org 1440061922 2843 80.91.229.3 (20 Aug 2015 09:12:02 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 20 Aug 2015 09:12:02 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBDL6FI4NYYERBUNT22XAKGQE46DMMNQ@isocpp.org Thu Aug 20 11:11:58 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ig0-f197.google.com ([209.85.213.197]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZSLt2-0007Bc-9p for gclcip-std-proposals@m.gmane.org; Thu, 20 Aug 2015 11:11:52 +0200 Original-Received: by igcse8 with SMTP id se8sf44065867igc.1 for ; Thu, 20 Aug 2015 02:11:46 -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=TMrfGDlWH6/gebwAWpyh0NRXE4lgdVC/8N8A2x+n+a8=; b=ABSwjz4AeFaDIA3I7ZqnPlN6zSucylDapZE8I7nzmALDGcWlrLtc4hn1Mcya9XeJ7m Dc9ebBCAkwOkNUz8Ga69xgOfB8rCTqpha6heHtLOWJfOCv7uhq82o/aU+L/UnpvEBNjd Tx1pZimoe+FnXR1mUGOKWR1UDxr7ZooC2RdZc32yN9SbA3fbW402Q149+Lgtw8XRFl/y MWpMkfykQmGAQtviQgbtveADHEgp49CgZ7Mh8GLwNA/n2vrFPGltNRmH5Pu4UB/xqQ4L WyOl2xCclN8Zx6Jeu4ETr4ulkHGab2qiazGPv9GZ6UM1RSYclwIKGtFKhxtX8WlwXxym 0LEA== 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=TMrfGDlWH6/gebwAWpyh0NRXE4lgdVC/8N8A2x+n+a8=; b=P9owRVYbm30vO+WFhvsoxbqJXtZR3Gx2SjnkY71KvkxwvJWv4w5jfg20BpjmB4XHbA 5KzUY2hE4my/YcIK6kWwCAVVMH3pJAhWKWGH6g2s0FlgUhXfVSKv2fYV7h6hqsGi+aDL 9+EdGlNeVHczDgz7Y8lO4uxPz91UoJuJPdSKsylllGYxKwvQ+azLLAK0UUBx+muI5jrk Ts7c4ycArQY/whogANPAZC9SA4pZXIRTWKabxa+lDiMK2A9y0dgzNz0Tp13ADmGjNEW6 MtADW+HeBoCJ7pktoetIFVajUn2fgC/xVBrlncVdPa2IpEAYUyJLKoCayToIppWsJXWR qe1Q== X-Gm-Message-State: ALoCoQmxdepdySVLgKm/s6E86eUAsf2Mpc/HmBU5wIUAfeyJcOkl9+rpoah1V4NiGftB4STCHOXc X-Received: by 10.182.49.233 with SMTP id x9mr1562074obn.0.1440061906231; Thu, 20 Aug 2015 02:11:46 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.140.87.119 with SMTP id q110ls642004qgd.22.gmail; Thu, 20 Aug 2015 02:11:44 -0700 (PDT) X-Received: by 10.140.16.168 with SMTP id 37mr18188qgb.28.1440061904633; Thu, 20 Aug 2015 02:11:44 -0700 (PDT) In-Reply-To: X-Original-Sender: atch.cpp@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:19941 Archived-At: ------=_Part_133_1006987662.1440061903824 Content-Type: multipart/alternative; boundary="----=_Part_134_2055303384.1440061903824" ------=_Part_134_2055303384.1440061903824 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I would urge you to read my post again and not the smily icon at the end of= =20 my sentece, and just mention, that as well as I made mistake judging=20 @dgutson's sense of humor you've made identical mistake not realizing that= =20 I'm simply joking with David. On Wednesday, 19 August 2015 19:13:56 UTC+1, Brent Friedman wrote: > > Arthur, please refrain from implying that someone needs to go back to=20 > elementary school based on your personal interpretation of something that= =20 > someone else said. Also, if you know of an elementary school that teaches= =20 > C++ then I'd love to hear about it. > > The notion that every single class ever needs to have strict encapsulatio= n=20 > for every single data member is fairly ridiculous in my opinion.=20 > Encapsulation is a tool used to achieve certain software engineering goal= s=20 > and it can be misused like any other tool. > > > On Wed, Aug 19, 2015 at 1:07 PM, Arthur Tchaikovsky > wrote: > >> Not all members in struct are public. From elementary school, everyone= =20 >> knows that struct differs from class that *by default* members are publi= c=20 >> in struct and private in class. ;) >> That's why I see it as a violation of encapsulation. Secondly, not only= =20 >> structs should be concerned, but classes too. And not only initializatio= n=20 >> should be a concern here but also setting value *after* the object had b= een=20 >> initialized. Taken all this above, I say that accessing members of a=20 >> class/struct by names, be it during initialization or after that fact is= =20 >> violation of encapsulation and it should be discouraged in modern C++. T= his=20 >> kind of code may very well be OK for C but C++ is not C.=20 >> >> On Wednesday, 19 August 2015 18:50:13 UTC+1, David Rodr=C3=ADguez Ibeas = wrote: >>> >>> How does that violate an encapsulation that does not exist? All members= =20 >>> are public in the struct=E2=80=A6 you might dislike it on different acc= ounts but=20 >>> encapsulation is not an issue with that code. Other pro=C2=B4s, the ar= guments=20 >>> are named, which is stable across refactors that might shift the positi= ons=20 >>> (assuming sensible names, the caller wants the 'a' to have value X or t= he=20 >>> 'b' to have value Z. Depending on the position of the member in the str= uct=20 >>> (and passing 'default' if needed for the previous arguments) is *more*= =20 >>> coupled, not less coupled. >>> >>> For initialization of structs, the C way is clearly better than the C++= =20 >>> way here. A different question is whether we want to put some effort in= to=20 >>> that part of the language when we can assume that most types are not=20 >>> all-members-public.=20 >>> >>> Then again this is only related to default arguments to functions in=20 >>> that uniform initialization would be even less uniform in certain cases= .. I=20 >>> do see the problems with named arguments, I still think that to be the= =20 >>> better way. Whether initialization of structs can be made compatible wi= th C=20 >>> once again=E2=80=A6 would be nice here, but I imagine not that many peo= ple care. >>> >>> David >>> >>> On Wed, Aug 19, 2015 at 5:27 PM, Arthur Tchaikovsky = =20 >>> wrote: >>> >>>> It *is not* simpler. What you've just shown is a violation of=20 >>>> encapsulation. Not simplification. >>>> >>>> >>>> On Wednesday, 19 August 2015 16:08:52 UTC+1, S.B. wrote: >>>>> >>>>> It's even simpler if we could write=20 >>>>> >>>>> struct s { >>>>> int a =3D 1337; >>>>> int b =3D 4096; >>>>> }; >>>>> =20 >>>>> 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=20 >>>>>> asserted named arguments are not going to happen anytime soon (if at= all). >>>>>> >>>>>> Earlier in this thread there were workarounds listed which are more= =20 >>>>>> or less comparable to the proposal in their effect. >>>>>> I would like to elaborate some more on one of these workarounds, as= =20 >>>>>> it can be mapped pretty much 1-to-1 to the proposal and it happens t= o be=20 >>>>>> 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)=20 >>>>>> : a(a), b(b) { } >>>>>> int a; >>>>>> int b; >>>>>> }; >>>>>> =20 >>>>>> 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)=20 >>>>>> : a(a), b(b) { } >>>>>> int a; >>>>>> int b; >>>>>> }; >>>>>> =20 >>>>>> 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= =20 >>>>>> z(s::default_b, 42)` - Oops, passed `default_b` as `a`.) >>>>>> 3) When looking up the actual default values there is one more hop t= o=20 >>>>>> make. It's not sufficient to look at the function declaration but=20 >>>>>> additionally we have to look for e.g. default_a. >>>>>> >>>>>> --=20 >>>> >>>> ---=20 >>>> You received this message because you are subscribed to the Google=20 >>>> Groups "ISO C++ Standard - Future Proposals" group. >>>> To unsubscribe from this group and stop receiving emails from it, send= =20 >>>> an email to std-proposal...@isocpp.org. >>>> To post to this group, send email to std-pr...@isocpp.org. >>>> Visit this group at=20 >>>> http://groups.google.com/a/isocpp.org/group/std-proposals/. >>>> >>> >>> --=20 >> >> ---=20 >> You received this message because you are subscribed to the Google Group= s=20 >> "ISO C++ Standard - Future Proposals" group. >> To unsubscribe from this group and stop receiving emails from it, send a= n=20 >> email to std-proposal...@isocpp.org . >> To post to this group, send email to std-pr...@isocpp.org . >> Visit this group at=20 >> 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/. ------=_Part_134_2055303384.1440061903824 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I would urge you to read my post again and not the smily i= con at the end of my sentece, and just mention, that as well as I made mist= ake judging @dgutson's sense of humor you've made identical mistake= not realizing that I'm simply joking with David.

On Wednesday, = 19 August 2015 19:13:56 UTC+1, Brent Friedman wrote:
Arthur, please refrain from implyin= g that someone needs to go back to elementary school based on your personal= interpretation of something that someone else said. Also, if you know of a= n elementary school that teaches C++ then I'd love to hear about it.
The notion that every single class ever needs to have stri= ct encapsulation for every single data member is fairly ridiculous in my op= inion. Encapsulation is a tool used to achieve certain software engineering= goals and it can be misused like any other tool.


On Wed, Aug 19, 2015 at 1:07 PM, Arthu= r Tchaikovsky <atch...@gmail.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
Not all members in struct ar= e public. From elementary school, everyone knows that struct differs from c= lass that *by default* members are public in struct and private in class. ;= )
That's why I see it as a violation of encapsulation. Secondly, not= only structs should be concerned, but classes too. And not only initializa= tion should be a concern here but also setting value *after* the object had= been initialized. Taken all this above, I say that accessing members of a = class/struct by names, be it during initialization or after that fact is vi= olation of encapsulation and it should be discouraged in modern C++. This k= ind of code may very well be OK for C but C++ is not C.

On We= dnesday, 19 August 2015 18:50:13 UTC+1, David Rodr=C3=ADguez Ibeas wrote:<= /span>
How do= es that violate an encapsulation that does not exist? All members are publi= c in the struct=E2=80=A6 you might dislike it on different accounts but enc= apsulation is not an issue with that code.=C2=A0 Other pro=C2=B4s, the argu= ments are named, which is stable across refactors that might shift the posi= tions (assuming sensible names, the caller wants the 'a' to have va= lue X or the 'b' to have value Z. Depending on the position of the = member in the struct (and passing 'default' if needed for the previ= ous arguments) is *more* coupled, not less coupled.

For = initialization of structs, the C way is clearly better than the C++ way her= e. A different question is whether we want to put some effort into that par= t of the language when we can assume that most types are not all-members-pu= blic.=C2=A0

Then again this is only related to def= ault arguments to functions in that uniform initialization would be even le= ss uniform in certain cases.=C2=A0 I do see the problems with named argumen= ts, I still think that to be the better way. Whether initialization of stru= cts can be made compatible with C once again=E2=80=A6 would be nice here, b= ut 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...@gmail.com> wrote:
It *is not* s= impler. What you've just shown is a violation of encapsulation. Not sim= plification.


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;<= br>=C2=A0 =C2=A0 int b =3D 4096;
};
=C2=A0
int main() {
=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 ret= urn 0;
}

:)

On W= ednesday, 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 all).

Earlier in this thread there were workarounds listed w= hich are more or less comparable to the proposal in their effect.
I woul= d like to elaborate some more on one of these workarounds, as it can be map= ped pretty much 1-to-1 to the proposal and it happens to be the solution I = employ when encountering this kind of problem.


# Current workarou= nd.

struct s {
=C2=A0 =C2=A0 static int const default_a =3D 1337;<= br>=C2=A0 =C2=A0 static int const default_b =3D 4096;
=C2=A0 =C2=A0 s(in= t a =3D default_a, int 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::default_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.

<= div>

--

---
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-proposal...@isocpp.org.
To post to this group, send email to std-pr...@isocpp.o= rg.
Visit this group at http://groups.google.com/a/i= socpp.org/group/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-proposal...@isocpp.org.
To post to this group, send email to std-pr...@isocpp.org.
Visit this group at http://groups.google.com/a/i= socpp.org/group/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>.
------=_Part_134_2055303384.1440061903824-- ------=_Part_133_1006987662.1440061903824-- .