Topic: Designated Initializer List Status
Author: Bryce Glover <randomdsdevel@gmail.com>
Date: Mon, 23 Nov 2015 17:37:49 -0500
Raw View
--Apple-Mail=_C9275565-58B8-47CA-86B0-4007C40CFA6A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
> On Nov 21, 2015, at 3:12 PM, std-proposals@isocpp.org wrote:
>=20
> std-proposals@isocpp.org <https://groups.google.com/a/isocpp.org/forum/?u=
tm_source=3Ddigest&utm_medium=3Demail#!forum/std-proposals/topics> Google G=
roups <https://groups.google.com/a/isocpp.org/forum/?utm_source=3Ddigest&ut=
m_medium=3Demail/#!overview> <https://groups.google.com/a/isocpp.org/forum=
/?utm_source=3Ddigest&utm_medium=3Demail/#!overview> =20
> Topic digest <>
> View all topics <https://groups.google.com/a/isocpp.org/forum/?utm_source=
=3Ddigest&utm_medium=3Demail#!forum/std-proposals/topics>
> Designated initializer list status? <x-msg://3/#group_thread_0> - 9 Updat=
es
> (snipped=E2=80=A6)
> <>Designated initializer list status? <http://groups.google.com/a/i=
socpp.org/group/std-proposals/t/f3be47f4496485dc?utm_source=3Ddigest&utm_me=
dium=3Demail> =20
> (snipped)
> Nicol Bolas <jmckesson@gmail.com>: Nov 21 09:56AM -0800=20
>=20
> (snipped)
> =E2=8B=AE
>=20
> I would also suggest that any such proposal not have "improve parity with=
=20
> C" as its primary motivation (or in the case of the above, *only*=20
> motivation). More convincing motivations should revolve around using it i=
n=20
> C++ code. What can you do with it that you can't do without it. The fact=
=20
> that it's in C is a good way to prove that the idea works, but that alone=
=20
> is hardly sufficient motivation for a C++ feature.
> =20
> For example, there was a discussion awhile back about named parameters=20
> <https://groups.google.com/a/isocpp.org/d/msg/std-proposals/3iegpTsMuT0/h=
gmDlYkWIgAJ <https://groups.google.com/a/isocpp.org/d/msg/std-proposals/3ie=
gpTsMuT0/hgmDlYkWIgAJ>>.=20
> It lead to the revelation that, if you have designated initializers, you=
=20
> can more or less get that. The function would take a single struct type,=
=20
> and you would call it with `funcName({.param1 =3D X, .param2 =3D Y, etc})=
`.=20
> Naturally, they wanted to add language functionality to remove the parens=
,=20
> but that's unnecessary. The main point is to give people an easy way to=
=20
> pass named parameters to a function, and designated initializers would=20
> allow precisely that. =20
>=20
> =E2=8B=AE
>=20
> (snipped)
> =E2=8B=AE
>=20
> (snipped)
> Back to top <x-msg://3/#digest_top>
> You received this digest because you're subscribed to updates for this gr=
oup. You can change your settings on the group membership page <https://gro=
ups.google.com/a/isocpp.org/forum/?utm_source=3Ddigest&utm_medium=3Demail#!=
forum/std-proposals/join>.
> To unsubscribe from this group and stop receiving emails from it send an =
email to std-proposals+unsubscribe@isocpp.org <mailto:std-proposals+unsubsc=
ribe@isocpp.org>.
Even though I=E2=80=99m only speaking about this from an end-user pers=
pective, I agree with the points that Nicol Bolas made in the part of that =
e-mail of his which I quoted above. In particular, I agree that a formal p=
roposal to add C99=E2=80=99s designated initializers into C++(17?) should d=
ress the concerns that he raised in the first paragraph I quoted. One of t=
he examples that this paper could use to indicate possible use cases could =
indeed be the one that he referenced in his second paragraph, but the propo=
sal=E2=80=99s author might also want to mention that, if I understand and r=
emember correctly, there is already a workaround for this in the form of me=
thod chaining. That technique, however, seems to be a bit of kludge to me,=
especially since it takes an entity emitted from an initial function call =
and performs one or more transformations on it using more functions when a =
programmer may really have intended to pass multiple arguments to a single =
function, thus avoiding the expenses involved in setting up and tearing dow=
n multiple stack frames. =20
=E2=80=94=E2=80=89Bryce Glover
=E3=80=80=E2=80=89RandomDSdevel@gmail.com
--=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/.
--Apple-Mail=_C9275565-58B8-47CA-86B0-4007C40CFA6A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><div><blockquote t=
ype=3D"cite" class=3D""><div class=3D"">On Nov 21, 2015, at 3:12 PM, <a hre=
f=3D"mailto:std-proposals@isocpp.org" class=3D"">std-proposals@isocpp.org</=
a> wrote:</div><br class=3D"Apple-interchange-newline"><div class=3D"">
<div style=3D"border: 1px solid rgb(211, 211, 211); max-width: 850px; font-=
family: Arial, sans-serif;" class=3D"">
<div style=3D"background-color:#f5f5f5;padding:10px 20px" class=3D"">
<table cellpadding=3D"0" cellspacing=3D"0" style=3D"width:100%" class=
=3D"">
<tbody class=3D"">
<tr class=3D"">
<td style=3D"width:70%" class=3D"">
<span style=3D"font:18px/20px arial;color:#333333" class=3D"">
<a href=3D"https://groups.google.com/a/isocpp.org/forum/?utm_=
source=3Ddigest&utm_medium=3Demail#!forum/std-proposals/topics" style=
=3D"text-decoration:none; color:#333333" class=3D"">
std-proposals@isocpp.org</a>
</span>
</td>
<td style=3D"text-align:right;width:30%" class=3D"">
<span style=3D"font:20px/24px arial" class=3D""><a style=3D"col=
or:#dd4b39; text-decoration:none;" href=3D"https://groups.google.com/a/isoc=
pp.org/forum/?utm_source=3Ddigest&utm_medium=3Demail/#!overview" target=
=3D"_blank" class=3D"">Google Groups</a></span>
</td>
<td style=3D"width:32px;" class=3D"">
<a href=3D"https://groups.google.com/a/isocpp.org/forum/?utm_so=
urce=3Ddigest&utm_medium=3Demail/#!overview" target=3D"_blank" class=3D=
""><img style=3D"border:0;vertical-align:middle" src=3D"http://www.google.c=
om/images/icons/product/groups-32.png" class=3D""></a>
</td>
</tr>
</tbody>
</table>
</div>
<div style=3D"padding:20px; background-color: #f5f5f5;" class=3D"">
<div style=3D"font-family: arial; color: #222222; padding: 0px" class=3D"">
<a name=3D"digest_top" style=3D"font-size:21px;" class=3D"">
=20
=20
Topic digest
=20
</a><br class=3D"">
<span style=3D"font-size:11px" class=3D"">
<a style=3D"color:#1155cc;text-decoration:none" href=3D"https://groups.=
google.com/a/isocpp.org/forum/?utm_source=3Ddigest&utm_medium=3Demail#!=
forum/std-proposals/topics" class=3D"">View all topics</a>
</span>
</div>
<div style=3D"font: 13px/18px arial; color:#222222; padding: 0px; margin-bo=
ttom:30px" class=3D"">
<ul style=3D"margin-left:3px; padding-left:0px" class=3D"">
=20
<li class=3D"">
<a style=3D"color:#1155cc;text-decoration:none" href=3D"x-msg://3/#gr=
oup_thread_0" class=3D"">
Designated initializer list status?</a> -
<span style=3D"color:#777777" class=3D"">9 Updates</span></li></ul></=
div></div></div></div></blockquote><blockquote type=3D"cite" class=3D"">(sn=
ipped=E2=80=A6)<br class=3D""></blockquote><blockquote type=3D"cite" class=
=3D""><div style=3D"border: 1px solid rgb(211, 211, 211); max-width: 850px;=
font-family: Arial, sans-serif;" class=3D""><div style=3D"padding:20px; ba=
ckground-color: #f5f5f5;" class=3D""><div style=3D"font: 13px/18px arial; c=
olor:#222222; padding: 0px; margin-bottom:30px" class=3D""><ul style=3D"mar=
gin-left:3px; padding-left:0px" class=3D"">
=20
</ul>
</div>
=20
<a name=3D"group_thread_0" class=3D""></a>
<div style=3D"display:inline-block; font-family: arial; padding: 4px 0 5p=
x 0px;" class=3D"">
=20
<a target=3D"_blank" href=3D"http://groups.google.com/a/isocpp.org/grou=
p/std-proposals/t/f3be47f4496485dc?utm_source=3Ddigest&utm_medium=3Dema=
il" style=3D"font-size:21px; color:#1155CC; text-decoration:none" class=3D"=
">
Designated initializer list status?
</a>
=20
</div>
<table style=3D"border-collapse: collapse; width: 100%" class=3D"">
=20
<tbody class=3D""><tr class=3D""><td style=3D"background-color: rgb(2=
55, 255, 255); font-family: arial; padding: 10px 15px; border: 1px solid rg=
b(211, 211, 211);" class=3D""><font color=3D"#b1b0b0" class=3D""><span styl=
e=3D"font-size: 15px;" class=3D"">(snipped)</span></font></td></tr>
=20
<tr class=3D""><td style=3D"background-color: #FFFFFF; color:#2E2E2E;=
font-family: arial; padding:10px 15px; border:1px solid #d3d3d3;" class=3D=
"">
<span style=3D"color:#B1B0B0; font-size: 15px;" class=3D"">
Nicol Bolas <<a href=3D"mailto:jmckesson@gmail.com" class=3D""=
>jmckesson@gmail.com</a>>: Nov 21 09:56AM -0800
</span>
<br class=3D""><br class=3D"">(snipped)<br class=3D"">=E2=8B=AE<br =
class=3D""><br class=3D"">I would also suggest that any such proposal not h=
ave "improve parity with <br class=3D"">
C" as its primary motivation (or in the case of the above, *only* <br class=
=3D"">
motivation). More convincing motivations should revolve around using it in =
<br class=3D"">
C++ code. What can you do with it that you can't do without it. The fact <b=
r class=3D"">
that it's in C is a good way to prove that the idea works, but that alone <=
br class=3D"">
is hardly sufficient motivation for a C++ feature.<br class=3D"">
<br class=3D"">
For example, there was a discussion awhile back about named parameters <br =
class=3D"">
<<a href=3D"https://groups.google.com/a/isocpp.org/d/msg/std-proposals/3=
iegpTsMuT0/hgmDlYkWIgAJ" class=3D"">https://groups.google.com/a/isocpp.org/=
d/msg/std-proposals/3iegpTsMuT0/hgmDlYkWIgAJ</a>>. <br class=3D"">
It lead to the revelation that, if you have designated initializers, you <b=
r class=3D"">
can more or less get that. The function would take a single struct type, <b=
r class=3D"">
and you would call it with `funcName({.param1 =3D X, .param2 =3D Y, etc})`.=
<br class=3D"">
Naturally, they wanted to add language functionality to remove the parens, =
<br class=3D"">
but that's unnecessary. The main point is to give people an easy way to <br=
class=3D"">
pass named parameters to a function, and designated initializers would <br =
class=3D"">
allow precisely that. <br class=3D"">
<br class=3D"">=E2=8B=AE<br class=3D""><br class=3D"">(snipped)</td></tr>
=20
<tr class=3D""><td style=3D"background-color: rgb(255, 255, 255); fon=
t-family: arial; padding: 10px 15px; border: 1px solid rgb(211, 211, 211);"=
class=3D""><font color=3D"#b1b0b0" class=3D""><span style=3D"font-size: 15=
px;" class=3D"">=E2=8B=AE<br class=3D""><br class=3D"">(snipped)</span></fo=
nt></td></tr>
=20
</tbody></table>
<div style=3D"align:right; font-size:11px; margin-bottom: 40px; margin-to=
p:5px;" class=3D"">
<a style=3D"color:#1155cc;text-decoration:none" href=3D"x-msg://3/#dige=
st_top" class=3D"">Back to top</a></div></div><div style=3D"background-colo=
r: #f5f5f5;padding: 5px 20px;" class=3D""><table cellpadding=3D"0" cellspac=
ing=3D"0" style=3D"width:100%" class=3D"">
<tbody class=3D""><tr class=3D"">
<td style=3D"padding-top:4px;font-family:arial,sans-serif;color:#636363=
;font-size:11px" class=3D"">
=20
You received this digest because you're subscribed to updates for thi=
s group. You can change your settings on the <a href=3D"https://groups.goog=
le.com/a/isocpp.org/forum/?utm_source=3Ddigest&utm_medium=3Demail#!foru=
m/std-proposals/join" style=3D"color:#1155cc;text-decoration:none" class=3D=
"">group membership page</a>.<br class=3D"">
To unsubscribe from this group and stop receiving emails from it send=
an email to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" class=
=3D"">std-proposals+unsubscribe@isocpp.org</a>.
</td>
</tr></tbody>
</table>
</div>
</div>
</blockquote></div><br class=3D""><div class=3D""> Even =
though I=E2=80=99m only speaking about this from an end-user perspective, I=
agree with the points that Nicol Bolas made in the part of that e-mail of =
his which I quoted above. In particular, I agree that a formal propos=
al to add C99=E2=80=99s designated initializers into C++(17?) should dress =
the concerns that he raised in the first paragraph I quoted. One of t=
he examples that this paper could use to indicate possible use cases could =
indeed be the one that he referenced in his second paragraph, but the propo=
sal=E2=80=99s author might also want to mention that, if I understand and r=
emember correctly, there is already a workaround for this in the form of me=
thod chaining. That technique, however, seems to be a bit of kludge t=
o me, especially since it takes an entity emitted from an initial function =
call and performs one or more transformations on it using more functions wh=
en a programmer may really have intended to pass multiple arguments to a <i=
class=3D"">single</i> function, thus avoiding the expenses involved i=
n setting up and tearing down multiple stack frames. </div><div class=
=3D""><br class=3D"webkit-block-placeholder"></div><div apple-content-edite=
d=3D"true" class=3D"">
<div style=3D"color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; t=
ext-align: start; text-indent: 0px; text-transform: none; white-space: norm=
al; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-w=
rap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-=
space;" class=3D""><div style=3D"color: rgb(0, 0, 0); letter-spacing: norma=
l; orphans: auto; text-align: start; text-indent: 0px; text-transform: none=
; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke=
-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-=
break: after-white-space;" class=3D""><div class=3D"">=E2=80=94=E2=80=89Bry=
ce Glover</div><div class=3D"">=E3=80=80=E2=80=89<a href=3D"mailto:RandomDS=
devel@gmail.com" class=3D"">RandomDSdevel@gmail.com</a></div></div></div>
</div>
<br class=3D""></body></html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--Apple-Mail=_C9275565-58B8-47CA-86B0-4007C40CFA6A--
.
Author: Patrice Roy <patricer@gmail.com>
Date: Mon, 23 Nov 2015 20:30:41 -0500
Raw View
--001a11c3a57c3306df05253f4a70
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
The nice thing about method chaining is that it does not force maintenance
of specific names that were not previously part of the type and function
interfaces (apart from documentation purposes). This proposal seems to me
to be imposing an unneeded burden on interfaces, and there are indeed many
workarounds.
Named arguments are less annoying in C where things such as encapsulation
are not as big a concern. I understand better why they allow it there.
I'd have to see a very convincing argument to go for this proposal, to be
honest, given the downsides.
2015-11-23 17:37 GMT-05:00 Bryce Glover <randomdsdevel@gmail.com>:
> On Nov 21, 2015, at 3:12 PM, std-proposals@isocpp.org wrote:
>
> std-proposals@isocpp.org
> <https://groups.google.com/a/isocpp.org/forum/?utm_source=3Ddigest&utm_me=
dium=3Demail#!forum/std-proposals/topics> Google
> Groups
> <https://groups.google.com/a/isocpp.org/forum/?utm_source=3Ddigest&utm_me=
dium=3Demail/#!overview>
> <https://groups.google.com/a/isocpp.org/forum/?utm_source=3Ddigest&utm_me=
dium=3Demail/#!overview>
> Topic digest
> View all topics
> <https://groups.google.com/a/isocpp.org/forum/?utm_source=3Ddigest&utm_me=
dium=3Demail#!forum/std-proposals/topics>
>
> - Designated initializer list status? - 9 Updates
>
> (snipped=E2=80=A6)
>
>
>
> Designated initializer list status?
> <http://groups.google.com/a/isocpp.org/group/std-proposals/t/f3be47f44964=
85dc?utm_source=3Ddigest&utm_medium=3Demail>
> (snipped) Nicol Bolas <jmckesson@gmail.com>: Nov 21 09:56AM -0800
>
> (snipped)
> =E2=8B=AE
>
> I would also suggest that any such proposal not have "improve parity with
> C" as its primary motivation (or in the case of the above, *only*
> motivation). More convincing motivations should revolve around using it i=
n
> C++ code. What can you do with it that you can't do without it. The fact
> that it's in C is a good way to prove that the idea works, but that alone
> is hardly sufficient motivation for a C++ feature.
>
> For example, there was a discussion awhile back about named parameters
> <
> https://groups.google.com/a/isocpp.org/d/msg/std-proposals/3iegpTsMuT0/hg=
mDlYkWIgAJ>.
>
> It lead to the revelation that, if you have designated initializers, you
> can more or less get that. The function would take a single struct type,
> and you would call it with `funcName({.param1 =3D X, .param2 =3D Y, etc})=
`.
> Naturally, they wanted to add language functionality to remove the parens=
,
> but that's unnecessary. The main point is to give people an easy way to
> pass named parameters to a function, and designated initializers would
> allow precisely that.
>
> =E2=8B=AE
>
> (snipped) =E2=8B=AE
>
> (snipped)
> Back to top
> You received this digest because you're subscribed to updates for this
> group. You can change your settings on the group membership page
> <https://groups.google.com/a/isocpp.org/forum/?utm_source=3Ddigest&utm_me=
dium=3Demail#!forum/std-proposals/join>
> .
> To unsubscribe from this group and stop receiving emails from it send an
> email to std-proposals+unsubscribe@isocpp.org.
>
>
> Even though I=E2=80=99m only speaking about this from an end-user
> perspective, I agree with the points that Nicol Bolas made in the part of
> that e-mail of his which I quoted above. In particular, I agree that a
> formal proposal to add C99=E2=80=99s designated initializers into C++(17?=
) should
> dress the concerns that he raised in the first paragraph I quoted. One o=
f
> the examples that this paper could use to indicate possible use cases cou=
ld
> indeed be the one that he referenced in his second paragraph, but the
> proposal=E2=80=99s author might also want to mention that, if I understan=
d and
> remember correctly, there is already a workaround for this in the form of
> method chaining. That technique, however, seems to be a bit of kludge to
> me, especially since it takes an entity emitted from an initial function
> call and performs one or more transformations on it using more functions
> when a programmer may really have intended to pass multiple arguments to =
a
> *single* function, thus avoiding the expenses involved in setting up and
> tearing down multiple stack frames.
>
> =E2=80=94 Bryce Glover
> RandomDSdevel@gmail.com
>
> --
>
> ---
> 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/.
--001a11c3a57c3306df05253f4a70
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><div><div>The nice thing about method chaining is tha=
t it does not force maintenance of specific names that were not previously =
part of the type and function interfaces (apart from documentation purposes=
). This proposal seems to me to be imposing an unneeded burden on interface=
s, and there are indeed many workarounds.<br><br></div><div>Named arguments=
are less annoying in C where things such as encapsulation are not as big a=
concern. I understand better why they allow it there.<br><br></div><div>I&=
#39;d have to see a very convincing argument to go for this proposal, to be=
honest, given the downsides.<br></div></div></div><br></div><div class=3D"=
gmail_extra"><br><div class=3D"gmail_quote">2015-11-23 17:37 GMT-05:00 Bryc=
e Glover <span dir=3D"ltr"><<a href=3D"mailto:randomdsdevel@gmail.com" t=
arget=3D"_blank">randomdsdevel@gmail.com</a>></span>:<br><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pa=
dding-left:1ex"><div style=3D"word-wrap:break-word"><div><blockquote type=
=3D"cite"><div>On Nov 21, 2015, at 3:12 PM, <a href=3D"mailto:std-proposals=
@isocpp.org" target=3D"_blank">std-proposals@isocpp.org</a> wrote:</div><br=
><div>
<div style=3D"border:1px solid rgb(211,211,211);max-width:850px;font-family=
:Arial,sans-serif">
<div style=3D"background-color:#f5f5f5;padding:10px 20px">
<table style=3D"width:100%" cellpadding=3D"0" cellspacing=3D"0">
<tbody>
<tr>
<td style=3D"width:70%">
<span style=3D"font:18px/20px arial;color:#333333">
<a href=3D"https://groups.google.com/a/isocpp.org/forum/?utm_=
source=3Ddigest&utm_medium=3Demail#!forum/std-proposals/topics" style=
=3D"text-decoration:none;color:#333333" target=3D"_blank">
std-proposals@isocpp.org</a>
</span>
</td>
<td style=3D"text-align:right;width:30%">
<span style=3D"font:20px/24px arial"><a style=3D"color:#dd4b39;=
text-decoration:none" href=3D"https://groups.google.com/a/isocpp.org/forum/=
?utm_source=3Ddigest&utm_medium=3Demail/#!overview" target=3D"_blank">G=
oogle Groups</a></span>
</td>
<td style=3D"width:32px">
<a href=3D"https://groups.google.com/a/isocpp.org/forum/?utm_so=
urce=3Ddigest&utm_medium=3Demail/#!overview" target=3D"_blank"><img sty=
le=3D"border:0;vertical-align:middle" src=3D"http://www.google.com/images/i=
cons/product/groups-32.png"></a>
</td>
</tr>
</tbody>
</table>
</div>
<div style=3D"padding:20px;background-color:#f5f5f5">
<div style=3D"font-family:arial;color:#222222;padding:0px">
<a name=3D"151367f089dd10a2_digest_top" style=3D"font-size:21px">
=20
=20
Topic digest
=20
</a><br>
<span style=3D"font-size:11px">
<a style=3D"color:#1155cc;text-decoration:none" href=3D"https://groups.=
google.com/a/isocpp.org/forum/?utm_source=3Ddigest&utm_medium=3Demail#!=
forum/std-proposals/topics" target=3D"_blank">View all topics</a>
</span>
</div>
<div style=3D"font:13px/18px arial;color:#222222;padding:0px;margin-bottom:=
30px">
<ul style=3D"margin-left:3px;padding-left:0px">
=20
<li>
<a style=3D"color:#1155cc;text-decoration:none">
Designated initializer list status?</a> -
<span style=3D"color:#777777">9 Updates</span></li></ul></div></div><=
/div></div></blockquote><blockquote type=3D"cite">(snipped=E2=80=A6)<br></b=
lockquote><blockquote type=3D"cite"><div style=3D"border:1px solid rgb(211,=
211,211);max-width:850px;font-family:Arial,sans-serif"><div style=3D"paddin=
g:20px;background-color:#f5f5f5"><div style=3D"font:13px/18px arial;color:#=
222222;padding:0px;margin-bottom:30px"><ul style=3D"margin-left:3px;padding=
-left:0px">
=20
</ul>
</div>
=20
<a name=3D"151367f089dd10a2_group_thread_0"></a>
<div style=3D"display:inline-block;font-family:arial;padding:4px 0 5px 0p=
x">
=20
<a href=3D"http://groups.google.com/a/isocpp.org/group/std-proposals/t/=
f3be47f4496485dc?utm_source=3Ddigest&utm_medium=3Demail" style=3D"font-=
size:21px;color:#1155cc;text-decoration:none" target=3D"_blank">
Designated initializer list status?
</a>
=20
</div>
<table style=3D"border-collapse:collapse;width:100%">
=20
<tbody><tr><td style=3D"background-color:rgb(255,255,255);font-family=
:arial;padding:10px 15px;border:1px solid rgb(211,211,211)"><font color=3D"=
#b1b0b0"><span style=3D"font-size:15px">(snipped)</span></font></td></tr>
=20
<tr><td style=3D"background-color:#ffffff;color:#2e2e2e;font-family:a=
rial;padding:10px 15px;border:1px solid #d3d3d3">
<span style=3D"color:#b1b0b0;font-size:15px">
Nicol Bolas <<a href=3D"mailto:jmckesson@gmail.com" target=3D"=
_blank">jmckesson@gmail.com</a>>: Nov 21 09:56AM -0800
</span>
<br><br>(snipped)<br>=E2=8B=AE<br><br>I would also suggest that any=
such proposal not have "improve parity with <br>
C" as its primary motivation (or in the case of the above, *only* <br>
motivation). More convincing motivations should revolve around using it in =
<br>
C++ code. What can you do with it that you can't do without it. The fac=
t <br>
that it's in C is a good way to prove that the idea works, but that alo=
ne <br>
is hardly sufficient motivation for a C++ feature.<br>
=C2=A0<br>
For example, there was a discussion awhile back about named parameters <br>
<<a href=3D"https://groups.google.com/a/isocpp.org/d/msg/std-proposals/3=
iegpTsMuT0/hgmDlYkWIgAJ" target=3D"_blank">https://groups.google.com/a/isoc=
pp.org/d/msg/std-proposals/3iegpTsMuT0/hgmDlYkWIgAJ</a>>. <br>
It lead to the revelation that, if you have designated initializers, you <b=
r>
can more or less get that. The function would take a single struct type, <b=
r>
and you would call it with `funcName({.param1 =3D X, .param2 =3D Y, etc})`.=
<br>
Naturally, they wanted to add language functionality to remove the parens, =
<br>
but that's unnecessary. The main point is to give people an easy way to=
<br>
pass named parameters to a function, and designated initializers would <br>
allow precisely that. =C2=A0<br>
<br>=E2=8B=AE<br><br>(snipped)</td></tr>
=20
<tr><td style=3D"background-color:rgb(255,255,255);font-family:arial;=
padding:10px 15px;border:1px solid rgb(211,211,211)"><font color=3D"#b1b0b0=
"><span style=3D"font-size:15px">=E2=8B=AE<br><br>(snipped)</span></font></=
td></tr>
=20
</tbody></table>
<div style=3D"font-size:11px;margin-bottom:40px;margin-top:5px">
<a style=3D"color:#1155cc;text-decoration:none">Back to top</a></div></=
div><div style=3D"background-color:#f5f5f5;padding:5px 20px"><table style=
=3D"width:100%" cellpadding=3D"0" cellspacing=3D"0">
<tbody><tr>
<td style=3D"padding-top:4px;font-family:arial,sans-serif;color:#636363=
;font-size:11px">
=20
You received this digest because you're subscribed to updates for=
this group. You can change your settings on the <a href=3D"https://groups.=
google.com/a/isocpp.org/forum/?utm_source=3Ddigest&utm_medium=3Demail#!=
forum/std-proposals/join" style=3D"color:#1155cc;text-decoration:none" targ=
et=3D"_blank">group membership page</a>.<br>
To unsubscribe from this group and stop receiving emails from it send=
an email to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=
=3D"_blank">std-proposals+unsubscribe@isocpp.org</a>.
</td>
</tr></tbody>
</table>
</div>
</div>
</blockquote></div><br><div>=C2=A0 =C2=A0 =C2=A0Even though I=E2=80=99m onl=
y speaking about this from an end-user perspective, I agree with the points=
that Nicol Bolas made in the part of that e-mail of his which I quoted abo=
ve.=C2=A0 In particular, I agree that a formal proposal to add C99=E2=80=99=
s designated initializers into C++(17?) should dress the concerns that he r=
aised in the first paragraph I quoted.=C2=A0 One of the examples that this =
paper could use to indicate possible use cases could indeed be the one that=
he referenced in his second paragraph, but the proposal=E2=80=99s author m=
ight also want to mention that, if I understand and remember correctly, the=
re is already a workaround for this in the form of method chaining.=C2=A0 T=
hat technique, however, seems to be a bit of kludge to me, especially since=
it takes an entity emitted from an initial function call and performs one =
or more transformations on it using more functions when a programmer may re=
ally have intended to pass multiple arguments to a <i>single</i>=C2=A0funct=
ion, thus avoiding the expenses involved in setting up and tearing down mul=
tiple stack frames. =C2=A0</div><span class=3D"HOEnZb"><font color=3D"#8888=
88"><div><br></div><div>
<div style=3D"color:rgb(0,0,0);letter-spacing:normal;text-align:start;text-=
indent:0px;text-transform:none;white-space:normal;word-spacing:0px;word-wra=
p:break-word"><div style=3D"color:rgb(0,0,0);letter-spacing:normal;text-ali=
gn:start;text-indent:0px;text-transform:none;white-space:normal;word-spacin=
g:0px;word-wrap:break-word"><div>=E2=80=94=E2=80=89Bryce Glover</div><div>=
=E3=80=80=E2=80=89<a href=3D"mailto:RandomDSdevel@gmail.com" target=3D"_bla=
nk">RandomDSdevel@gmail.com</a></div></div></div>
</div>
<br></font></span></div><span class=3D"HOEnZb"><font color=3D"#888888">
<p></p>
-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</font></span></blockquote></div><br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a11c3a57c3306df05253f4a70--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Mon, 23 Nov 2015 19:41:52 -0800 (PST)
Raw View
------=_Part_6099_1093995729.1448336512935
Content-Type: multipart/alternative;
boundary="----=_Part_6100_1804140490.1448336512936"
------=_Part_6100_1804140490.1448336512936
Content-Type: text/plain; charset=UTF-8
On Monday, November 23, 2015 at 8:30:43 PM UTC-5, Patrice Roy wrote:
>
> The nice thing about method chaining is that it does not force maintenance
> of specific names that were not previously part of the type and function
> interfaces (apart from documentation purposes). This proposal seems to me
> to be imposing an unneeded burden on interfaces, and there are indeed many
> workarounds.
>
> Named arguments are less annoying in C where things such as encapsulation
> are not as big a concern. I understand better why they allow it there.
>
> I'd have to see a very convincing argument to go for this proposal, to be
> honest, given the downsides.
>
We're not talking about "named arguments". We're talking about designated
initializers, which could be used to give the effects of named arguments,
but are useful for more than just that.
--
---
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_6100_1804140490.1448336512936
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Monday, November 23, 2015 at 8:30:43 PM UTC-5, =
Patrice Roy wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"=
ltr"><div><div><div>The nice thing about method chaining is that it does no=
t force maintenance of specific names that were not previously part of the =
type and function interfaces (apart from documentation purposes). This prop=
osal seems to me to be imposing an unneeded burden on interfaces, and there=
are indeed many workarounds.<br><br></div><div>Named arguments are less an=
noying in C where things such as encapsulation are not as big a concern. I =
understand better why they allow it there.<br><br></div><div>I'd have t=
o see a very convincing argument to go for this proposal, to be honest, giv=
en the downsides.<br></div></div></div></div></blockquote><div><br>We'r=
e not talking about "named arguments". We're talking about de=
signated initializers, which could be used to give the effects of named arg=
uments, but are useful for more than just that.</div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_6100_1804140490.1448336512936--
------=_Part_6099_1093995729.1448336512935--
.
Author: Patrice Roy <patricer@gmail.com>
Date: Tue, 24 Nov 2015 11:52:33 -0500
Raw View
--001a11c3db70087de605254c2bd9
Content-Type: text/plain; charset=UTF-8
I understand the usefulness and the distinction, but the point stands: so
far, the interface downsides seem to weigh much more than the syntactic
advantages. As many have said, usefulness is not sufficient, particularly
if the feature has strong pain points.
2015-11-23 22:41 GMT-05:00 Nicol Bolas <jmckesson@gmail.com>:
>
>
> On Monday, November 23, 2015 at 8:30:43 PM UTC-5, Patrice Roy wrote:
>>
>> The nice thing about method chaining is that it does not force
>> maintenance of specific names that were not previously part of the type and
>> function interfaces (apart from documentation purposes). This proposal
>> seems to me to be imposing an unneeded burden on interfaces, and there are
>> indeed many workarounds.
>>
>> Named arguments are less annoying in C where things such as encapsulation
>> are not as big a concern. I understand better why they allow it there.
>>
>> I'd have to see a very convincing argument to go for this proposal, to be
>> honest, given the downsides.
>>
>
> We're not talking about "named arguments". We're talking about designated
> initializers, which could be used to give the effects of named arguments,
> but are useful for more than just that.
>
> --
>
> ---
> 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/.
>
--
---
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/.
--001a11c3db70087de605254c2bd9
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>I understand the usefulness and the distinction, but =
the point stands: so far, the interface downsides seem to weigh much more t=
han the syntactic advantages. As many have said, usefulness is not sufficie=
nt, particularly if the feature has strong pain points.<br><br></div></div>=
<div class=3D"gmail_extra"><br><div class=3D"gmail_quote">2015-11-23 22:41 =
GMT-05:00 Nicol Bolas <span dir=3D"ltr"><<a href=3D"mailto:jmckesson@gma=
il.com" target=3D"_blank">jmckesson@gmail.com</a>></span>:<br><blockquot=
e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol=
id;padding-left:1ex"><div dir=3D"ltr"><span class=3D""><br><br>On Monday, N=
ovember 23, 2015 at 8:30:43 PM UTC-5, Patrice Roy wrote:<blockquote class=
=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><div dir=3D"ltr"><div><div><div>The nice thing about=
method chaining is that it does not force maintenance of specific names th=
at were not previously part of the type and function interfaces (apart from=
documentation purposes). This proposal seems to me to be imposing an unnee=
ded burden on interfaces, and there are indeed many workarounds.<br><br></d=
iv><div>Named arguments are less annoying in C where things such as encapsu=
lation are not as big a concern. I understand better why they allow it ther=
e.<br><br></div><div>I'd have to see a very convincing argument to go f=
or this proposal, to be honest, given the downsides.<br></div></div></div><=
/div></blockquote></span><div><br>We're not talking about "named a=
rguments". We're talking about designated initializers, which coul=
d be used to give the effects of named arguments, but are useful for more t=
han just that.</div></div><div class=3D"HOEnZb"><div class=3D"h5">
<p></p>
-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a11c3db70087de605254c2bd9--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Tue, 24 Nov 2015 09:09:26 -0800 (PST)
Raw View
------=_Part_775_440408000.1448384966759
Content-Type: multipart/alternative;
boundary="----=_Part_776_1882187545.1448384966759"
------=_Part_776_1882187545.1448384966759
Content-Type: text/plain; charset=UTF-8
On Tuesday, November 24, 2015 at 11:52:36 AM UTC-5, Patrice Roy wrote:
>
> I understand the usefulness and the distinction, but the point stands: so
> far, the interface downsides seem to weigh much more than the syntactic
> advantages. As many have said, usefulness is not sufficient, particularly
> if the feature has strong pain points.
>
Interface downsides of what? There is no interface. Remember: the idea is
for designated initializers, not named arguments. The latter is merely a
potential application of the former.
--
---
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_776_1882187545.1448384966759
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Tuesday, November 24, 2015 at 11:52:36 AM UTC-5, Patric=
e Roy wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><=
div>I understand the usefulness and the distinction, but the point stands: =
so far, the interface downsides seem to weigh much more than the syntactic =
advantages. As many have said, usefulness is not sufficient, particularly i=
f the feature has strong pain points.<br></div></div></blockquote><div><br>=
Interface downsides of what? There is no interface. Remember: the idea is f=
or designated initializers, not named arguments. The latter is merely a pot=
ential application of the former.<br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_776_1882187545.1448384966759--
------=_Part_775_440408000.1448384966759--
.
Author: Patrice Roy <patricer@gmail.com>
Date: Tue, 24 Nov 2015 12:21:29 -0500
Raw View
--001a1141977e7f9ad105254c925a
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Maybe I'm misunderstanding your point. Tell me where I'm wrong:
- In a simple aggregate with public data members, designated
initializers would let us initialize data members through their names,
which is not a problem as the names are part on the interface. This is n=
ot
a problem for me
- In a class with private data members and its ctors, or with a function
signature in general, designated initializers would let us use the
arguments by name, circumventing the link between the order of arguments=
on
the caller's side and on the callee's side. This is not necessarily a ba=
d
thing, except that it binds the names in the caller code to the names in
the callee's signature. This name binding is a serious bother in my view=
; I
do not see this =C2=ABaddition=C2=BB to the callee's interface as a posi=
tive feature
(to say the least)
If I'm misunderstanding the proposal on this last point, then I might have
missed how the link between the names used in client code and in the called
functions is made (it's quite possible). Unless I'm mistaken, there will
need to be a by-name link somewhere, which seems to me like a maintenance
problem anywhere but where those names were already public and documented
as such in the first place.
Cheers!
2015-11-24 12:09 GMT-05:00 Nicol Bolas <jmckesson@gmail.com>:
> On Tuesday, November 24, 2015 at 11:52:36 AM UTC-5, Patrice Roy wrote:
>>
>> I understand the usefulness and the distinction, but the point stands: s=
o
>> far, the interface downsides seem to weigh much more than the syntactic
>> advantages. As many have said, usefulness is not sufficient, particularl=
y
>> if the feature has strong pain points.
>>
>
> Interface downsides of what? There is no interface. Remember: the idea is
> for designated initializers, not named arguments. The latter is merely a
> potential application of the former.
>
> --
>
> ---
> 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/.
--001a1141977e7f9ad105254c925a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><div><div><div>Maybe I'm misunderstanding your po=
int. Tell me where I'm wrong:<br><br></div><ul><li>In a simple aggregat=
e with public data members, designated initializers would let us initialize=
data members through their names, which is not a problem as the names are =
part on the interface. This is not a problem for me</li><li>In a class with=
private data members and its ctors, or with a function signature in genera=
l, designated initializers would let us use the arguments by name, circumve=
nting the link between the order of arguments on the caller's side and =
on the callee's side. This is not necessarily a bad thing, except that =
it binds the names in the caller code to the names in the callee's sign=
ature. This name binding is a serious bother in my view; I do not see this =
=C2=ABaddition=C2=BB to the callee's interface as a positive feature (t=
o say the least)</li></ul></div><br></div>If I'm misunderstanding the p=
roposal on this last point, then I might have missed how the link between t=
he names used in client code and in the called functions is made (it's =
quite possible). Unless I'm mistaken, there will need to be a by-name l=
ink somewhere, which seems to me like a maintenance problem anywhere but wh=
ere those names were already public and documented as such in the first pla=
ce.<br><br></div>Cheers!<br><div><br></div></div><div class=3D"gmail_extra"=
><br><div class=3D"gmail_quote">2015-11-24 12:09 GMT-05:00 Nicol Bolas <spa=
n dir=3D"ltr"><<a href=3D"mailto:jmckesson@gmail.com" target=3D"_blank">=
jmckesson@gmail.com</a>></span>:<br><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div =
dir=3D"ltr"><span class=3D"">On Tuesday, November 24, 2015 at 11:52:36 AM U=
TC-5, Patrice Roy wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0=
;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D=
"ltr"><div>I understand the usefulness and the distinction, but the point s=
tands: so far, the interface downsides seem to weigh much more than the syn=
tactic advantages. As many have said, usefulness is not sufficient, particu=
larly if the feature has strong pain points.<br></div></div></blockquote></=
span><div><br>Interface downsides of what? There is no interface. Remember:=
the idea is for designated initializers, not named arguments. The latter i=
s merely a potential application of the former.<br></div></div><div class=
=3D"HOEnZb"><div class=3D"h5">
<p></p>
-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a1141977e7f9ad105254c925a--
.
Author: Sean Middleditch <sean.middleditch@gmail.com>
Date: Tue, 24 Nov 2015 09:48:45 -0800 (PST)
Raw View
------=_Part_3488_420018017.1448387325276
Content-Type: multipart/alternative;
boundary="----=_Part_3489_52240174.1448387325277"
------=_Part_3489_52240174.1448387325277
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Tuesday, November 24, 2015 at 9:21:30 AM UTC-8, Patrice Roy wrote:
>
> Maybe I'm misunderstanding your point. Tell me where I'm wrong:
>
>
> - In a simple aggregate with public data members, designated=20
> initializers would let us initialize data members through their names,=
=20
> which is not a problem as the names are part on the interface. This is=
not=20
> a problem for me
> - In a class with private data members and its ctors, or with a=20
> function signature in general, designated initializers would let us us=
e the=20
> arguments by name, circumventing the link between the order of argumen=
ts on=20
> the caller's side and on the callee's side. This is not necessarily a =
bad=20
> thing, except that it binds the names in the caller code to the names =
in=20
> the callee's signature. This name binding is a serious bother in my vi=
ew; I=20
> do not see this =C2=ABaddition=C2=BB to the callee's interface as a po=
sitive feature=20
> (to say the least)
>
>
> If I'm misunderstanding the proposal on this last point, then I might hav=
e=20
> missed how the link between the names used in client code and in the call=
ed=20
> functions is made (it's quite possible). Unless I'm mistaken, there will=
=20
> need to be a by-name link somewhere, which seems to me like a maintenance=
=20
> problem anywhere but where those names were already public and documented=
=20
> as such in the first place.
>
He isn't proposing anything that needs that. He doesn't want to support=20
constructors and wants only designated initialization of aggregates (i.e.=
=20
simple structs, maybe with base class support tossed in).
I, not he, argued that this non-holistic design is the wrong approach for=
=20
C++ and that constructors must be considered for this feature to be worth=
=20
taking to and through the committee.
Yes, any serious proposal that does involve function parameter names would=
=20
most absolutely have to provide a way to opt-in to having the names become=
=20
part of the API, with the default for them to not. This opt-in would either=
=20
be at the function declaration via some new [use of a] [contextual] keyword=
=20
or sigil or even be per-parameter.
My original treatise of the subject some ~6-12 months ago started out with=
=20
a position identical (or very similar) to Jason's: get aggregate designated=
=20
initializers through the committee first by themselves, then see about=20
extending that to constructors as a second proposal, then the coup de grace=
=20
of named parameters. My opinion on the matter has evolved since then.=20
> Cheers!
>
>
> 2015-11-24 12:09 GMT-05:00 Nicol Bolas <jmck...@gmail.com <javascript:>>:
>
>> On Tuesday, November 24, 2015 at 11:52:36 AM UTC-5, Patrice Roy wrote:
>>>
>>> I understand the usefulness and the distinction, but the point stands:=
=20
>>> so far, the interface downsides seem to weigh much more than the syntac=
tic=20
>>> advantages. As many have said, usefulness is not sufficient, particular=
ly=20
>>> if the feature has strong pain points.
>>>
>>
>> Interface downsides of what? There is no interface. Remember: the idea i=
s=20
>> for designated initializers, not named arguments. The latter is merely a=
=20
>> potential application of the former.
>>
>> --=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 <javascript:>.
>> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>> 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_3489_52240174.1448387325277
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<br><br>On Tuesday, November 24, 2015 at 9:21:30 AM UTC-8, Patrice Roy wrot=
e:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;b=
order-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div><=
div><div>Maybe I'm misunderstanding your point. Tell me where I'm w=
rong:<br><br></div><ul><li>In a simple aggregate with public data members, =
designated initializers would let us initialize data members through their =
names, which is not a problem as the names are part on the interface. This =
is not a problem for me</li><li>In a class with private data members and it=
s ctors, or with a function signature in general, designated initializers w=
ould let us use the arguments by name, circumventing the link between the o=
rder of arguments on the caller's side and on the callee's side. Th=
is is not necessarily a bad thing, except that it binds the names in the ca=
ller code to the names in the callee's signature. This name binding is =
a serious bother in my view; I do not see this =C2=ABaddition=C2=BB to the =
callee's interface as a positive feature (to say the least)</li></ul></=
div><br></div>If I'm misunderstanding the proposal on this last point, =
then I might have missed how the link between the names used in client code=
and in the called functions is made (it's quite possible). Unless I=
9;m mistaken, there will need to be a by-name link somewhere, which seems t=
o me like a maintenance problem anywhere but where those names were already=
public and documented as such in the first place.<br></div></div></blockqu=
ote><div><br></div><div>He isn't proposing anything that needs that. He=
doesn't want to support constructors and wants only designated initial=
ization of aggregates (i.e. simple structs, maybe with base class support t=
ossed in).</div><div><br></div><div>I, not he, argued that this non-holisti=
c design is the wrong approach for C++ and that constructors must be consid=
ered for this feature to be worth taking to and through the committee.</div=
><div><br></div><div><div>Yes, any serious proposal that does involve funct=
ion parameter names would most absolutely have to provide a way to opt-in t=
o having the names become part of the API, with the default for them to not=
.. This opt-in would either be at the function declaration via some new [use=
of a] [contextual] keyword or sigil or even be per-parameter.<br></div></d=
iv><div><br></div><div>My original treatise of the subject some ~6-12 month=
s ago started out with a position identical (or very similar) to Jason'=
s: get aggregate designated initializers through the committee first by the=
mselves, then see about extending that to constructors as a second proposal=
, then the coup de grace of named parameters. My opinion on the matter has =
evolved since then.=C2=A0</div><div><br></div><blockquote class=3D"gmail_qu=
ote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padd=
ing-left: 1ex;"><div dir=3D"ltr"><div><br></div>Cheers!<br><div><br></div><=
/div><div><br><div class=3D"gmail_quote">2015-11-24 12:09 GMT-05:00 Nicol B=
olas <span dir=3D"ltr"><<a href=3D"javascript:" target=3D"_blank" gdf-ob=
fuscated-mailto=3D"O_VCvCOFBgAJ" rel=3D"nofollow" onmousedown=3D"this.href=
=3D'javascript:';return true;" onclick=3D"this.href=3D'javascri=
pt:';return true;">jmck...@gmail.com</a>></span>:<br><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pa=
dding-left:1ex"><div dir=3D"ltr"><span>On Tuesday, November 24, 2015 at 11:=
52:36 AM UTC-5, Patrice Roy wrote:<blockquote class=3D"gmail_quote" style=
=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"=
><div dir=3D"ltr"><div>I understand the usefulness and the distinction, but=
the point stands: so far, the interface downsides seem to weigh much more =
than the syntactic advantages. As many have said, usefulness is not suffici=
ent, particularly if the feature has strong pain points.<br></div></div></b=
lockquote></span><div><br>Interface downsides of what? There is no interfac=
e. Remember: the idea is for designated initializers, not named arguments. =
The latter is merely a potential application of the former.<br></div></div>=
<div><div>
<p></p>
-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
O_VCvCOFBgAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:&=
#39;;return true;" onclick=3D"this.href=3D'javascript:';return true=
;">std-proposal...@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"O_VCvCOFBgAJ" rel=3D"nofollow" onmousedown=3D"=
this.href=3D'javascript:';return true;" onclick=3D"this.href=3D'=
;javascript:';return true;">std-pr...@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=
=3D'http://groups.google.com/a/isocpp.org/group/std-proposals/';ret=
urn true;" onclick=3D"this.href=3D'http://groups.google.com/a/isocpp.or=
g/group/std-proposals/';return true;">http://groups.google.com/a/<wbr>i=
socpp.org/group/std-<wbr>proposals/</a>.<br>
</div></div></blockquote></div><br></div>
</blockquote>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_3489_52240174.1448387325277--
------=_Part_3488_420018017.1448387325276--
.
Author: Patrice Roy <patricer@gmail.com>
Date: Tue, 24 Nov 2015 12:56:32 -0500
Raw View
--001a1136ac52e54c0f05254d0f9f
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Thanks for the precisions. Cheers!
2015-11-24 12:48 GMT-05:00 Sean Middleditch <sean.middleditch@gmail.com>:
>
>
> On Tuesday, November 24, 2015 at 9:21:30 AM UTC-8, Patrice Roy wrote:
>>
>> Maybe I'm misunderstanding your point. Tell me where I'm wrong:
>>
>>
>> - In a simple aggregate with public data members, designated
>> initializers would let us initialize data members through their names=
,
>> which is not a problem as the names are part on the interface. This i=
s not
>> a problem for me
>> - In a class with private data members and its ctors, or with a
>> function signature in general, designated initializers would let us u=
se the
>> arguments by name, circumventing the link between the order of argume=
nts on
>> the caller's side and on the callee's side. This is not necessarily a=
bad
>> thing, except that it binds the names in the caller code to the names=
in
>> the callee's signature. This name binding is a serious bother in my v=
iew; I
>> do not see this =C2=ABaddition=C2=BB to the callee's interface as a p=
ositive feature
>> (to say the least)
>>
>>
>> If I'm misunderstanding the proposal on this last point, then I might
>> have missed how the link between the names used in client code and in th=
e
>> called functions is made (it's quite possible). Unless I'm mistaken, the=
re
>> will need to be a by-name link somewhere, which seems to me like a
>> maintenance problem anywhere but where those names were already public a=
nd
>> documented as such in the first place.
>>
>
> He isn't proposing anything that needs that. He doesn't want to support
> constructors and wants only designated initialization of aggregates (i.e.
> simple structs, maybe with base class support tossed in).
>
> I, not he, argued that this non-holistic design is the wrong approach for
> C++ and that constructors must be considered for this feature to be worth
> taking to and through the committee.
>
> Yes, any serious proposal that does involve function parameter names woul=
d
> most absolutely have to provide a way to opt-in to having the names becom=
e
> part of the API, with the default for them to not. This opt-in would eith=
er
> be at the function declaration via some new [use of a] [contextual] keywo=
rd
> or sigil or even be per-parameter.
>
> My original treatise of the subject some ~6-12 months ago started out wit=
h
> a position identical (or very similar) to Jason's: get aggregate designat=
ed
> initializers through the committee first by themselves, then see about
> extending that to constructors as a second proposal, then the coup de gra=
ce
> of named parameters. My opinion on the matter has evolved since then.
>
>
>> Cheers!
>>
>>
>> 2015-11-24 12:09 GMT-05:00 Nicol Bolas <jmck...@gmail.com>:
>>
>>> On Tuesday, November 24, 2015 at 11:52:36 AM UTC-5, Patrice Roy wrote:
>>>>
>>>> I understand the usefulness and the distinction, but the point stands:
>>>> so far, the interface downsides seem to weigh much more than the synta=
ctic
>>>> advantages. As many have said, usefulness is not sufficient, particula=
rly
>>>> if the feature has strong pain points.
>>>>
>>>
>>> Interface downsides of what? There is no interface. Remember: the idea
>>> is for designated initializers, not named arguments. The latter is mere=
ly a
>>> potential application of the former.
>>>
>>> --
>>>
>>> ---
>>> 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/.
--001a1136ac52e54c0f05254d0f9f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Thanks for the precisions. Cheers!<br></div><div class=3D"=
gmail_extra"><br><div class=3D"gmail_quote">2015-11-24 12:48 GMT-05:00 Sean=
Middleditch <span dir=3D"ltr"><<a href=3D"mailto:sean.middleditch@gmail=
..com" target=3D"_blank">sean.middleditch@gmail.com</a>></span>:<br><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #cc=
c solid;padding-left:1ex"><span class=3D""><br><br>On Tuesday, November 24,=
2015 at 9:21:30 AM UTC-8, Patrice Roy wrote:<blockquote class=3D"gmail_quo=
te" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-=
left:1ex"><div dir=3D"ltr"><div><div><div><div>Maybe I'm misunderstandi=
ng your point. Tell me where I'm wrong:<br><br></div><ul><li>In a simpl=
e aggregate with public data members, designated initializers would let us =
initialize data members through their names, which is not a problem as the =
names are part on the interface. This is not a problem for me</li><li>In a =
class with private data members and its ctors, or with a function signature=
in general, designated initializers would let us use the arguments by name=
, circumventing the link between the order of arguments on the caller's=
side and on the callee's side. This is not necessarily a bad thing, ex=
cept that it binds the names in the caller code to the names in the callee&=
#39;s signature. This name binding is a serious bother in my view; I do not=
see this =C2=ABaddition=C2=BB to the callee's interface as a positive =
feature (to say the least)</li></ul></div><br></div>If I'm misunderstan=
ding the proposal on this last point, then I might have missed how the link=
between the names used in client code and in the called functions is made =
(it's quite possible). Unless I'm mistaken, there will need to be a=
by-name link somewhere, which seems to me like a maintenance problem anywh=
ere but where those names were already public and documented as such in the=
first place.<br></div></div></blockquote><div><br></div></span><div>He isn=
't proposing anything that needs that. He doesn't want to support c=
onstructors and wants only designated initialization of aggregates (i.e. si=
mple structs, maybe with base class support tossed in).</div><div><br></div=
><div>I, not he, argued that this non-holistic design is the wrong approach=
for C++ and that constructors must be considered for this feature to be wo=
rth taking to and through the committee.</div><div><br></div><div><div>Yes,=
any serious proposal that does involve function parameter names would most=
absolutely have to provide a way to opt-in to having the names become part=
of the API, with the default for them to not. This opt-in would either be =
at the function declaration via some new [use of a] [contextual] keyword or=
sigil or even be per-parameter.<br></div></div><div><br></div><div>My orig=
inal treatise of the subject some ~6-12 months ago started out with a posit=
ion identical (or very similar) to Jason's: get aggregate designated in=
itializers through the committee first by themselves, then see about extend=
ing that to constructors as a second proposal, then the coup de grace of na=
med parameters. My opinion on the matter has evolved since then.=C2=A0</div=
><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-=
left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><d=
iv><br></div>Cheers!<br><div><br></div></div><div><br><div class=3D"gmail_q=
uote"><span class=3D"">2015-11-24 12:09 GMT-05:00 Nicol Bolas <span dir=3D"=
ltr"><<a rel=3D"nofollow">jmck...@gmail.com</a>></span>:<br></span><b=
lockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px =
#ccc solid;padding-left:1ex"><span class=3D""><div dir=3D"ltr"><span>On Tue=
sday, November 24, 2015 at 11:52:36 AM UTC-5, Patrice Roy wrote:<blockquote=
class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px =
#ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>I understand the usefuln=
ess and the distinction, but the point stands: so far, the interface downsi=
des seem to weigh much more than the syntactic advantages. As many have sai=
d, usefulness is not sufficient, particularly if the feature has strong pai=
n points.<br></div></div></blockquote></span><div><br>Interface downsides o=
f what? There is no interface. Remember: the idea is for designated initial=
izers, not named arguments. The latter is merely a potential application of=
the former.<br></div></div></span><div><div><span class=3D"">
<p></p>
-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br></span>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a rel=3D"nofollow">std-proposal...@isocpp.org</a>.<br>
To post to this group, send email to <a rel=3D"nofollow">std-pr...@isocpp.o=
rg</a>.<span class=3D""><br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" rel=3D"nofollow" target=3D"_blank">http://groups.google.com=
/a/isocpp.org/group/std-proposals/</a>.<br>
</span></div></div></blockquote></div><br></div>
</blockquote><div class=3D"HOEnZb"><div class=3D"h5">
<p></p>
-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a1136ac52e54c0f05254d0f9f--
.