220 19929 <87b15f40-b36a-47bd-b822-8df53dd72287@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: Wed, 19 Aug 2015 11:07:00 -0700 (PDT) Lines: 328 Approved: news@gmane.org Message-ID: <87b15f40-b36a-47bd-b822-8df53dd72287@isocpp.org> 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/mixed; boundary="----=_Part_528_1346400368.1440007620379" X-Trace: ger.gmane.org 1440007631 7760 80.91.229.3 (19 Aug 2015 18:07:11 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 19 Aug 2015 18:07:11 +0000 (UTC) Cc: dibeas@ieee.org To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBDL6FI4NYYERBRML2OXAKGQENPGFGPA@isocpp.org Wed Aug 19 20:07:06 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-io0-f200.google.com ([209.85.223.200]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZS7lP-0003rR-TA for gclcip-std-proposals@m.gmane.org; Wed, 19 Aug 2015 20:07:04 +0200 Original-Received: by iods203 with SMTP id s203sf24691431iod.1 for ; Wed, 19 Aug 2015 11:07:02 -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=7gkrXtVGGUWXZEW/6zo8oocFaQUIukFMst/Xc04lmys=; b=ITnXW5JpVsGRQcREBgqym4s4YcXtoa5dQXhi/KB5c3HbufqxtDABCZ+Jr8rmklJzDR +o1KrktIOnQuUvuzuT3AaJkTOkSHK9vc2ivZgYYOr7EQXKtPhAYfogddp044iMCRBWWc i8wqxKAYGjLm+hDkniaS6l+opegKoy7XTr0mZTgT/mWgejX8YPabHVqeLkFfjnBCxVBe toRjVyuHk4nDBEgAAqep6Kp7XKNA65u7jpuH8ynFFVboBUHm3T5zIORbFh8lQdxGerNe wEEaBLXmykH/NiPJKngmOD88sa2yWKcRhA9c7eYwIwY8NlsttSwlY7Std/yzyU9BZD0M 3bUg== 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=7gkrXtVGGUWXZEW/6zo8oocFaQUIukFMst/Xc04lmys=; b=GUDTI53K/YwCQwousImlPb8/Bh+z9QGnKVuzPxfWVzTuacev2smqU32ZNCqAFUllvM lK6j2sp7Kt8Va75T2k77OxoSYeC8NbYoHu4V8M4TOH5jAqdjwtCZcIutsH2iSwd7xDEb VmibLPwGMNGUBODe1O03D3TmyNRux2dHZbpwI/IRZ1DY4B9HBj3gi4b7MN80qt6JxOaM CEnA2AgiicMfe8QiVUYgdcZvipoy+gKPmClpacOzXlBwTEujsWo+r4XHDdhSGkb4Wtv+ soke+W9s+w0Nzr0CNrRFoyLO05vMXcYh6EZTbHmSb7nAPwih1rHmWwYs2lBwbaJnQkGY DBtQ== X-Gm-Message-State: ALoCoQldqj67ZW2C68thOTWQ435Qp2ldO/p5YUiWmYVZ21vDGkqoFBqmzUk7CHdb/lPT8HBIQS/X X-Received: by 10.182.106.11 with SMTP id gq11mr11487786obb.25.1440007622813; Wed, 19 Aug 2015 11:07:02 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.140.106.55 with SMTP id d52ls316100qgf.53.gmail; Wed, 19 Aug 2015 11:07:01 -0700 (PDT) X-Received: by 10.140.96.14 with SMTP id j14mr191321qge.19.1440007621290; Wed, 19 Aug 2015 11:07:01 -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:19929 Archived-At: ------=_Part_528_1346400368.1440007620379 Content-Type: multipart/alternative; boundary="----=_Part_529_550259881.1440007620379" ------=_Part_529_550259881.1440007620379 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Not all members in struct are public. From elementary school, everyone=20 knows that struct differs from class that *by default* members are public= =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 initialization= =20 should be a concern here but also setting value *after* the object had been= =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++. This= =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 wro= te: > > 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 accou= nts but=20 > encapsulation is not an issue with that code. Other pro=C2=B4s, the argu= ments=20 > are named, which is stable across refactors that might shift the position= s=20 > (assuming sensible names, the caller wants the 'a' to have value X or the= =20 > 'b' to have value Z. Depending on the position of the member in the struc= t=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 into= =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 that= =20 > uniform initialization would be even less uniform in certain cases. I do= =20 > see the problems with named arguments, I still think that to be the bette= r=20 > way. Whether initialization of structs can be made compatible with C once= =20 > 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=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 a= ll). >>>> >>>> Earlier in this thread there were workarounds listed which are more or= =20 >>>> less comparable to the proposal in their effect. >>>> I would like to elaborate some more on one of these workarounds, as it= =20 >>>> can be mapped pretty much 1-to-1 to the proposal and it happens to be = the=20 >>>> 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 to= =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 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_529_550259881.1440007620379 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Not all members in struct are public. From elementary scho= ol, 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 a= s a violation of encapsulation. Secondly, not only structs should be concer= ned, but classes too. And not only initialization should be a concern here = but also setting value *after* the object had been initialized. Taken all t= his above, I say that accessing members of a class/struct by names, be it d= uring initialization or after that fact is violation of encapsulation and i= t should be discouraged in modern C++. This kind of code may very well be O= K for C but C++ is not C.

On Wednesday, 19 August 2015 18:50:13 UTC= +1, David Rodr=C3=ADguez Ibeas wrote:
How does that violate an encapsulation that does n= ot exist? All members are public in the struct=E2=80=A6 you might dislike i= t 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 re= factors 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 'def= ault' if needed for the previous arguments) is *more* coupled, not less= coupled.

For initialization of structs, the C way is cl= early 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.=C2=A0

Then = again this is only related to default arguments to functions in that unifor= m initialization would be even less uniform in certain cases.=C2=A0 I do se= e the problems with named arguments, I still think that to be the better wa= y. Whether initialization of structs can be made compatible with C once aga= in=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...@gmail.com> wrote:
It *is not* simpler. What you've just sh= own is a violation of encapsulation. Not simplification.


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

<= code>
struct s {<= br>=C2=A0 =C2=A0 int a =3D 1337;
=C2=A0 =C2=A0 int b =3D 4096;
};
=C2=A0
int<= span style=3D"color:#000"> main()<= span style=3D"color:#000"> {
=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 <= /span>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 na= med arguments are not going to happen anytime soon (if at all).

Earlier i= n this thread there were workarounds listed which are more or less comparab= le 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 {
=C2=A0= =C2=A0 static int const default_a =3D 1337;
=C2=A0 =C2=A0 static int co= nst default_b =3D 4096;
=C2=A0 =C2=A0 s(int a =3D default_a, int b =3D d= efault_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) { }<= br>=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(d= efault, 42);
=C2=A0 =C2=A0 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 actua= l 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 &= 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_529_550259881.1440007620379-- ------=_Part_528_1346400368.1440007620379-- .