220 19928 article Path: news.gmane.org!not-for-mail From: =?UTF-8?Q?David_Rodr=C3=ADguez_Ibeas?= Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: default arguments Date: Wed, 19 Aug 2015 18:50:09 +0100 Lines: 261 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=001a11c332da717d3f051dadaaa4 X-Trace: ger.gmane.org 1440006643 22985 80.91.229.3 (19 Aug 2015 17:50:43 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 19 Aug 2015 17:50:43 +0000 (UTC) To: "std-proposals@isocpp.org" Original-X-From: std-proposals+bncBDIIVO6GQULBBUUD2OXAKGQEFVFMJTQ@isocpp.org Wed Aug 19 19:50:28 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-la0-f72.google.com ([209.85.215.72]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZS7V7-0006Lz-DT for gclcip-std-proposals@m.gmane.org; Wed, 19 Aug 2015 19:50:13 +0200 Original-Received: by lagz9 with SMTP id z9sf3837761lag.3 for ; Wed, 19 Aug 2015 10:50:12 -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:sender: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=FsopPiGH6S9pKwBMPLmtjGxxtYRsydsPjTLPIKTLCds=; b=QHE8Q6C53dgsM4XaGg/PiV4BfRW4qnSMXfwtiPDYlNuTbw/RLt6wVhw8tJmSAJe9tk xvMUTB6ZDUy3oLf5xqu1zjfTzvUdb3e74YZXfXyz0VbbeecKBKcwKId6jXyAF9SeIC06 0dQHpiAewTI8fJkyxG1eob4WXUOzzjB1yVowfejnmvd3j3V2gaDaaPIKuIx4xayiP2PD m5xh+ms0MUiQMPZZEltj+UuFM8UJ75DF/9aOYfvQl0Z11xk5TdVS1Su4veLFS6GnigMm hWVrGO1Xhi6Ryni+iaxVRFQuH31++5a1hOXvEHiTMEihoYw/dfWYFYcKXldbMMP/x8vg zDGA== X-Gm-Message-State: ALoCoQmVDwkliJJ5MmPXtwvAw6WJeekyKaoQjICHDHRfK4bfqQt8M8nyUAbXTpEmIwgU58X4RVpO X-Received: by 10.112.50.10 with SMTP id y10mr3589354lbn.10.1440006612637; Wed, 19 Aug 2015 10:50:12 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.152.204.106 with SMTP id kx10ls59150lac.51.gmail; Wed, 19 Aug 2015 10:50:10 -0700 (PDT) X-Received: by 10.112.202.234 with SMTP id kl10mr12576022lbc.51.1440006610057; Wed, 19 Aug 2015 10:50:10 -0700 (PDT) Original-Received: from mail-lb0-x232.google.com (mail-lb0-x232.google.com. [2a00:1450:4010:c04::232]) by mx.google.com with ESMTPS id es12si1236936lbc.145.2015.08.19.10.50.10 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 19 Aug 2015 10:50:10 -0700 (PDT) Received-SPF: pass (google.com: domain of dribeas@gmail.com designates 2a00:1450:4010:c04::232 as permitted sender) client-ip=2a00:1450:4010:c04::232; Original-Received: by lbcbn3 with SMTP id bn3so8249342lbc.2 for ; Wed, 19 Aug 2015 10:50:10 -0700 (PDT) X-Received: by 10.112.139.133 with SMTP id qy5mr12439550lbb.60.1440006609663; Wed, 19 Aug 2015 10:50:09 -0700 (PDT) Original-Sender: dribeas@gmail.com Original-Received: by 10.114.196.103 with HTTP; Wed, 19 Aug 2015 10:50:09 -0700 (PDT) In-Reply-To: X-Original-Sender: dibeas@ieee.org X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of dribeas@gmail.com designates 2a00:1450:4010:c04::232 as permitted sender) smtp.mailfrom=dribeas@gmail.com; dkim=pass header.i=@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:19928 Archived-At: --001a11c332da717d3f051dadaaa4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 accounts bu= t encapsulation is not an issue with that code. Other pro=C2=B4s, the argume= nts 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 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 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. 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 al= l). >>> >>> 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 t= he >>> 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-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/. --001a11c332da717d3f051dadaaa4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
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 dif= ferent accounts but encapsulation is not an issue with that code.=C2=A0 Oth= er pro=C2=B4s, the arguments are named, which is stable across refactors th= at 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 the previous arguments) is *more* coupled, not less coupled.<= div>
For initialization of structs, the C way is clearly bett= er than the C++ way here. A different question is whether we want to put so= me 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 uniform initiali= zation would be even less uniform in certain cases.=C2=A0 I do see the prob= lems 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 = Tchaikovsky <atch.cpp@gmail.com> wrote:
It *is not* simpler. What you've just s= hown is a violation of encapsulation. Not simplification.


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

struct s {
=C2=A0 =C2=A0 int= a =3D<= span style=3D"color:#000"> 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 { .b =3D 42 };
=C2=A0 =C2=A0 return 0;
}

:)

On Wednesday, Augu= st 19, 2015 at 2:02:01 PM UTC+8, Max Truxa wrote:
I have to agree with Matt Calabrese completely. As it was alr= eady 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 elab= orate some more on one of these workarounds, as it can be mapped pretty muc= h 1-to-1 to the proposal and it happens to be the solution I employ when en= countering this kind of problem.


# Current workaround.

stru= ct s {
=C2=A0 =C2=A0 static int const default_a =3D 1337;
=C2=A0 =C2= =A0 static int const default_b =3D 4096;
=C2=A0 =C2=A0 s(int a =3D defau= lt_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 mai= n() {
=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 h= ere: 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 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 ho= p 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-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>.
--001a11c332da717d3f051dadaaa4-- .