220 19927 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 09:27:09 -0700 (PDT) Lines: 187 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/mixed; boundary="----=_Part_458_1030215788.1440001629518" X-Trace: ger.gmane.org 1440001648 5661 80.91.229.3 (19 Aug 2015 16:27:28 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 19 Aug 2015 16:27:28 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBDL6FI4NYYERBXW42KXAKGQEKDXAVXY@isocpp.org Wed Aug 19 18:27:16 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-vk0-f69.google.com ([209.85.213.69]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZS6Cm-0003qT-En for gclcip-std-proposals@m.gmane.org; Wed, 19 Aug 2015 18:27:12 +0200 Original-Received: by vkm66 with SMTP id 66sf8579471vkm.1 for ; Wed, 19 Aug 2015 09:27:11 -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=CPbC7VP75RRK4WJ0vC/kYjmvBWmLs731xPJ3TnXmK1E=; b=ZAqx+8xPAuNpVc5ACnPFADSspVFVwRGyxkVG0CP+loZvw11J3BXRe64LxWeJbZk1D2 4h51TmOw6+jZCVVkykEkIpC8B7eHX6MThiDXqle5iOr7ql4j8zKr7D4vpOP4byQH7S/J 1MV0q+vp3DDAkJU07u1AJ+q/qLHfNeRaGLYPBPcOhpak6qsDHZ5ICFU9dQzNH86B11wA nq5Vss0Rs4bFXklGjyjPhVonAYOomSt7r76bz58sh/Wn1gog1UZS7AGwsBVRQqs+0KLZ xNGi+bmeuHcFjPMLF0Wa6ynb+zoLWQI//F7TxbhWTFdcIxnAmbtCTWk4FomAxRuBCBoA YX4g== 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=CPbC7VP75RRK4WJ0vC/kYjmvBWmLs731xPJ3TnXmK1E=; b=kZoRCypG3YYUFLn1R1ZeoJzpMQOf4uwOtuqz1RgKFkZV2ROF2axbqU3DEjxjJV3qB0 CvqG2xvmlPE6xhq66azPRzEDz6GLDx8mWn3ru40UQImxGG+k9nhcakEVJr6XPKz+QF0L +DhpibpzT7mT0lJCFf2GaEIiFAXws0Ygm1Cd+3SJmR4FNOHppreZS6Ze1UHzZIdOjoMe jyaiSZd1LV9ts1HWhgBlwbeo/MNep0NKZvygUy/HuVWbE+D1A15W1+a6xHjWs3z22ime 279g2yy/vbCkchyDd+E/HccF5SEJKlyZKPW4jIHBJMaLgX7sTtoBcJ3m5ScGB4XwI4To hp2Q== X-Gm-Message-State: ALoCoQntRab49g7pypoPQ4jPVkRICqEZZz+HneoLoLM6nVKY2ZoPABUdrJSpbmzWO3tLL+QkRoIT X-Received: by 10.140.147.151 with SMTP id 145mr11073578qht.5.1440001631416; Wed, 19 Aug 2015 09:27:11 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.140.86.210 with SMTP id p76ls211260qgd.31.gmail; Wed, 19 Aug 2015 09:27:10 -0700 (PDT) X-Received: by 10.140.27.161 with SMTP id 30mr173503qgx.10.1440001630276; Wed, 19 Aug 2015 09:27:10 -0700 (PDT) In-Reply-To: <89bf9d09-00ed-45db-bf88-39c844707bd1@isocpp.org> 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:19927 Archived-At: ------=_Part_458_1030215788.1440001629518 Content-Type: multipart/alternative; boundary="----=_Part_459_863877001.1440001629519" ------=_Part_459_863877001.1440001629519 Content-Type: text/plain; charset=UTF-8 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 = 1337; > int b = 4096; > }; > > int main() { > s x; > s y { 42 }; // or s y { .a = 42 }; > s z { .b = 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 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 = 1337; >> static int const default_b = 4096; >> s(int a = default_a, int b = 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 = 1337, int b = 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/. ------=_Part_459_863877001.1440001629519 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
It *is not* simpler. What you've just shown is a viola= tion of encapsulation. Not simplification.

On Wednesday, 19 August 2= 015 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 <= span style=3D"color:#066">1337;
=C2=A0 =C2=A0 int b = =3D 409= 6;
<= /span>};
= =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, August 19, 2015 at 2:02:01 PM UTC+8, Max= Truxa wrote:
I have to agree with M= att Calabrese completely. As it was already asserted named arguments are no= t 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 i= n their effect.
I would like to elaborate some more on one of these work= arounds, as it can be mapped pretty much 1-to-1 to the proposal and it happ= ens to be the solution I employ when encountering this kind of problem.

=


# Current workaround.

struct s {
=C2=A0 =C2=A0 static int c= onst default_a =3D 1337;
=C2=A0 =C2=A0 static int const default_b =3D 40= 96;
=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/OKtbuc


# Using the pr= oposed 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 dr= awbacks.
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 value= s there is one more hop to make. It's not sufficient to look at the fun= ction declaration but additionally we have to look for e.g. default_a.

<= p>

--

---
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_459_863877001.1440001629519-- ------=_Part_458_1030215788.1440001629518-- .