220 19930 article Path: news.gmane.org!not-for-mail From: Brent Friedman Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: default arguments Date: Wed, 19 Aug 2015 13:13:55 -0500 Lines: 356 Approved: news@gmane.org Message-ID: 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/alternative; boundary=94eb2c0912546d21f2051dadfff8 X-Trace: ger.gmane.org 1440008045 14204 80.91.229.3 (19 Aug 2015 18:14:05 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 19 Aug 2015 18:14:05 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCHLPXGUXMJBBY4O2OXAKGQEUMIGFLY@isocpp.org Wed Aug 19 20:14:02 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-vk0-f72.google.com ([209.85.213.72]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZS7s5-0001Dw-Jp for gclcip-std-proposals@m.gmane.org; Wed, 19 Aug 2015 20:13:57 +0200 Original-Received: by vkd66 with SMTP id 66sf11235150vkd.3 for ; Wed, 19 Aug 2015 11:13:56 -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=qhIZbW75PcmUdytxNoIp9yeFKMSOlh73nNOeJbakxpY=; b=Lcbe++v46K0kLvth9ZzdYIhyY2eCJiFELvydWaH8KdTQzuEbud3YAXDfp1oN0Vtdtx Qj16EqeJLYhpWInZqem7dLtssNIVarqcij1MKBpz02ctuucww01/3dujl09R/NDqudLX Zrx1Bjc9UEIiurdT6H07tOu1+48sPoAUHO0RUODyNvoGQSRnBqwtN2w6rhzPUOtCHGOT 5ii0lM/IVaz/vfCu/hRgkXUbtlxzsop3HuGQbgWCI1U5PO7WUSzEpp0A4YBFRYZKhPyU bLeq5yPTwM0T3tbNgYsQAptdVgIYl8mYBsclZFzNv1RFzS/l2mdOXyDCmUFeh0LSyxqb IYOA== X-Gm-Message-State: ALoCoQnoQnMqIwAtBybDpi9wjEvCBUKXoT973R3eSFyAAHQtv3Q1GqkUVDH4TCrOfsjV3blgee8i X-Received: by 10.13.231.133 with SMTP id q127mr11745256ywe.31.1440008036360; Wed, 19 Aug 2015 11:13:56 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.182.29.41 with SMTP id g9ls84345obh.89.gmail; Wed, 19 Aug 2015 11:13:55 -0700 (PDT) X-Received: by 10.202.44.195 with SMTP id s186mr11350467ois.53.1440008035582; Wed, 19 Aug 2015 11:13:55 -0700 (PDT) Original-Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com. [2607:f8b0:4003:c06::235]) by mx.google.com with ESMTPS id pz7si23211oec.44.2015.08.19.11.13.55 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 19 Aug 2015 11:13:55 -0700 (PDT) Received-SPF: pass (google.com: domain of fourthgeek@gmail.com designates 2607:f8b0:4003:c06::235 as permitted sender) client-ip=2607:f8b0:4003:c06::235; Original-Received: by oiew67 with SMTP id w67so8175897oie.2 for ; Wed, 19 Aug 2015 11:13:55 -0700 (PDT) X-Received: by 10.202.239.138 with SMTP id n132mr10467970oih.99.1440008035441; Wed, 19 Aug 2015 11:13:55 -0700 (PDT) Original-Received: by 10.202.128.17 with HTTP; Wed, 19 Aug 2015 11:13:55 -0700 (PDT) In-Reply-To: <87b15f40-b36a-47bd-b822-8df53dd72287@isocpp.org> X-Original-Sender: fourthgeek@gmail.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of fourthgeek@gmail.com designates 2607:f8b0:4003:c06::235 as permitted sender) smtp.mailfrom=fourthgeek@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:19930 Archived-At: --94eb2c0912546d21f2051dadfff8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Arthur, please refrain from implying 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 an elementary school that teaches C++ then I'd love to hear about it. The notion that every single class ever needs to have strict encapsulation for every single data member is fairly ridiculous in my opinion. 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, Arthur Tchaikovsky wrote: > Not all members in struct are public. From elementary school, everyone > knows that struct differs from class 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 initialization > should be a concern here but also setting value *after* the object had be= en > 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 > violation of encapsulation and it should be discouraged in modern C++. Th= is > kind of code may very well be OK for C but C++ is not C. > > On Wednesday, 19 August 2015 18:50:13 UTC+1, David Rodr=C3=ADguez Ibeas w= rote: >> >> 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 acco= unts but >> encapsulation is not an issue with that code. Other pro=C2=B4s, the arg= uments >> are named, which is stable across refactors that might shift the positio= ns >> (assuming sensible names, the caller wants the 'a' to have value X or th= e >> 'b' to have value Z. Depending on the position of the member in the stru= ct >> (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 int= o >> 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 tha= t >> uniform initialization would be even less uniform in certain cases. I d= o >> see the problems with named arguments, I still think that to be the bett= er >> way. Whether initialization of structs can be made compatible with C onc= e >> again=E2=80=A6 would be nice here, but I imagine not that many people ca= re. >> >> 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 = all). >>>>> >>>>> Earlier in this thread there were workarounds listed which are more o= r >>>>> less comparable to the proposal in their effect. >>>>> I would like to elaborate some more on one of these workarounds, as i= t >>>>> 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 >>> Groups "ISO C++ Standard - Future Proposals" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email 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/isocpp.org/group/std-proposals/. >>> >> >> -- > > --- > 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/. > --=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/. --94eb2c0912546d21f2051dadfff8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Arthur, please refrain from implying that someone needs to= go back to elementary school based on your personal interpretation of some= thing that someone else said. Also, if you know of an elementary school tha= t teaches C++ then I'd love to hear about it.

The no= tion that every single class ever needs to have strict encapsulation for ev= ery single data member is fairly ridiculous in my opinion. Encapsulation is= a tool used to achieve certain software engineering goals and it can be mi= sused like any other tool.


On Wed, Aug 19, 2015 at 1:07 PM, Arthur= Tchaikovsky <atch.cpp@gmail.com> wrote:
Not all members in struct are public. From= elementary school, everyone knows that struct differs from class 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 initialization should be= a concern here but also setting value *after* the object had been initiali= zed. Taken all this above, I say that accessing members of a class/struct b= y names, be it during initialization or after that fact is violation of enc= apsulation and it should be discouraged in modern C++. This kind of code ma= y very well be OK for C but C++ is not C.

On Wedne= sday, 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 a= re public in the struct=E2=80=A6 you might dislike 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 refactors that might shift = the positions (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 struct (and passing 'default' if needed for t= he previous arguments) is *more* coupled, not less coupled.

<= div>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-me= mbers-public.=C2=A0

Then again this is only relate= d to default arguments to functions in that uniform initialization would be= even less uniform in certain cases.=C2=A0 I do see the problems with named= arguments, I still think that to be the better 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 care.

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

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


On Wedn= esday, 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 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 { <= /span>.b =3D <= span style=3D"color:#066">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 asserted named arg= uments 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 t= he 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 proposa= l and it happens to be the solution I employ when encountering this kind of= problem.


# Current workaround.

struct s {
=C2=A0 =C2=A0= static int const default_a =3D 1337;
=C2=A0 =C2=A0 static int const def= ault_b =3D 4096;
=C2=A0 =C2=A0 s(int 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/OK= tbuc


# 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 curr= ent solution has a number of drawbacks.
1) It's unnecessarily verbos= e.
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 look= ing up the actual default values there is one more hop to make. It's no= t sufficient to look at the function declaration but additionally we have t= o look for e.g. default_a.

<= div class=3D"h5">

--

---
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/isocpp.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-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 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>.
--94eb2c0912546d21f2051dadfff8-- .