On 5 October 2016 at 13:38, Marc Mutz <marc.mutz@kdab.com> wrote:
> In conjunction with auto deduction, the caller choosing the names means that
> the code becomes brittle in the face of changes to the return type, e.g. when
> reordering fields to fill padding holes.

There have been discussions about that, especially about fields change
their types.

>
> Structured Bindings would be acceptable if, like scripting languages, we
> didn't have anything else to work with.
>
> But we do: We can return a struct.

Structured bindings work with structs as well. If you think structured
bindings mean
you must return a tuple, you're mistaken.

> I fear Structured Bindings will lead to an explosion of *really* bad API that
> returns std::pair or std::tuple when it should return a small struct with

C++ programmers are not idiots.

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUYZDrLfm7QJtTiGEOdV52K3Kvv1ZdeKvoUfd2U2Ns32MA%40mail.gmail.com.

.

--047d7b86d05a643ffb053e1bdb74
Content-Type: text/plain; charset=UTF-8

The feature is already accepted. Only an NB comment can stop it now. Are
you a member of an NB?

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CACGiwhEohS5-wOedBbWCXvak8bZRrhVHeHOA-PjM0Mu5%2B6EtMg%40mail.gmail.com.

--047d7b86d05a643ffb053e1bdb74
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">The feature is already accepted. Only an NB comment can st=
op it now. Are you a member of an NB?<br><br></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CACGiwhEohS5-wOedBbWCXvak8bZRrhVHeHOA=
-PjM0Mu5%2B6EtMg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CACGiwhEohS5-wO=
edBbWCXvak8bZRrhVHeHOA-PjM0Mu5%2B6EtMg%40mail.gmail.com</a>.<br />

--047d7b86d05a643ffb053e1bdb74--

.

On 5 October 2016 at 13:44, D. B. <db0451@gmail.com> wrote:
> The feature is already accepted. Only an NB comment can stop it now. Are you
> a member of an NB?

For what it's worth, C++0x concepts were also accepted in a CD ballot.
NB comments are not
the only way to get facilities out of the standard.

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUapjJ%3DXeuPqD5pWr2yQA9yzbFFf5ToZJ-d%3Dh1e5YLrEiQ%40mail.gmail.com.

.

On Wednesday 05 October 2016 12:40:38 Ville Voutilainen wrote:
> On 5 October 2016 at 13:38, Marc Mutz <marc.mutz@kdab.com> wrote:
> > In conjunction with auto deduction, the caller choosing the names means
> > that the code becomes brittle in the face of changes to the return type,
> > e.g. when reordering fields to fill padding holes.
>
> There have been discussions about that, especially about fields change
> their types.

And? What was the outcome?

> > Structured Bindings would be acceptable if, like scripting languages, we
> > didn't have anything else to work with.
> >
> > But we do: We can return a struct.
>
> Structured bindings work with structs as well. If you think structured
> bindings mean
> you must return a tuple, you're mistaken.

Yes, I know that. But if I return a struct with proper names, I don't need SB
to handle it. Indeed, it would be counter-productive to have to find names for
SB if can access the names the implementor chose with C-space in my IDE from
the auto variable that stores the return type.

> > I fear Structured Bindings will lead to an explosion of *really* bad API
> > that returns std::pair or std::tuple when it should return a small
> > struct with
>
> C++ programmers are not idiots.

C++ programmers are humans, though.

We all make mistakes. Even Alex Stepanov did. The art is to not repeat them.

Thanks,
Marc

--
Marc Mutz <marc.mutz@kdab.com> | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - Qt, C++ and OpenGL Experts

.

--001a114a9686bae80e053e1ca664
Content-Type: text/plain; charset=UTF-8

>
> > > Structured Bindings would be acceptable if, like scripting languages,
> we
> > > didn't have anything else to work with.
> > >
> > > But we do: We can return a struct.
> >
> > Structured bindings work with structs as well. If you think structured
> > bindings mean
> > you must return a tuple, you're mistaken.
>
> Yes, I know that. But if I return a struct with proper names, I don't need
> SB
> to handle it. Indeed, it would be counter-productive to have to find names
> for
> SB if can access the names the implementor chose with C-space in my IDE
> from
> the auto variable that stores the return type.
>
>
So you're saying that returning a structure with error status and result or
multiple results of which you only need one or two (reason being for eg.
cheaper to return all at once - due to for e.g. web service call or complex
processing - than request one by one on need to basis) you would still
prefer dragging the entire structure around giving the feeling that your
code has more dependencies than it actually does? Pattern matching would
probably be better for some cases but it's sometimes nice to have a simpler
tool handy.


> > > I fear Structured Bindings will lead to an explosion of *really* bad
> API
> > > that returns std::pair or std::tuple when it should return a small
> > > struct with
> >
> > C++ programmers are not idiots.
>
> C++ programmers are humans, though.
>
> We all make mistakes. Even Alex Stepanov did. The art is to not repeat
> them.
>
>
This sounds like an argument for not having templates, pointers,
exceptions, probably even references or any other feature for that matter.

I have ideas on where to use this feature but like with all other features
it'd be pretty odd to sprinkle it around the code just because I can and
make odd library apis. Good, poor and all in between designs are already
present so I doubt that this feature will change that too much but I might
be wrong :)

Regards,
Domen

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAKgx6B%2BkywTPwYVRt3P5KDQ_%3DxMUuHzSJv6x21L5j1ExPz6bkQ%40mail.gmail.com.

--001a114a9686bae80e053e1ca664
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left=
:1px solid rgb(204,204,204);padding-left:1ex"><span class=3D"gmail-">
&gt; &gt; Structured Bindings would be acceptable if, like scripting langua=
ges, we<br>
&gt; &gt; didn&#39;t have anything else to work with.<br>
&gt; &gt;<br>
&gt; &gt; But we do: We can return a struct.<br>
&gt;<br>
&gt; Structured bindings work with structs as well. If you think structured=
<br>
&gt; bindings mean<br>
&gt; you must return a tuple, you&#39;re mistaken.<br>
<br>
</span>Yes, I know that. But if I return a struct with proper names, I don&=
#39;t need SB<br>
to handle it. Indeed, it would be counter-productive to have to find names =
for<br>
SB if can access the names the implementor chose with C-space in my IDE fro=
m<br>
the auto variable that stores the return type.<br>
<span class=3D"gmail-"><br></span></blockquote><div>=C2=A0</div><div>So you=
&#39;re saying that returning a structure with=20
error status and result or multiple results of which you only need one=20
or two (reason being for eg. cheaper to return all at once - due to for=20
e.g. web service call or complex processing - than request one by one on
 need to basis) you would still prefer dragging the entire structure=20
around giving the feeling that your code has more dependencies than it=20
actually does? Pattern matching would probably be better for some cases=20
but it&#39;s sometimes nice to have a simpler tool handy.<br>=C2=A0</div><b=
lockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-le=
ft:1px solid rgb(204,204,204);padding-left:1ex"><span class=3D"gmail-">
&gt; &gt; I fear Structured Bindings will lead to an explosion of *really* =
bad API<br>
&gt; &gt; that returns std::pair or std::tuple when it should return a smal=
l<br>
&gt; &gt; struct with<br>
&gt;<br>
&gt; C++ programmers are not idiots.<br>
<br>
</span>C++ programmers are humans, though.<br>
<br>
We all make mistakes. Even Alex Stepanov did. The art is to not repeat them=
..<br><br></blockquote><div>=C2=A0</div><div><div>This sounds like an argume=
nt for not having templates, pointers, exceptions, probably even references=
 or any other feature for that matter.<br><br>I
 have ideas on where to use this feature but like with all other=20
features it&#39;d be pretty odd to sprinkle it around the code just=20
because I can and make odd library apis. Good, poor and all in between desi=
gns are already present so I doubt that this feature will change that too m=
uch but I might be wrong :)<br></div><div><br></div><div>Regards,<br></div>=
Domen <br></div></div><br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAKgx6B%2BkywTPwYVRt3P5KDQ_%3DxMUuHzS=
Jv6x21L5j1ExPz6bkQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAKgx6B%2Bkyw=
TPwYVRt3P5KDQ_%3DxMUuHzSJv6x21L5j1ExPz6bkQ%40mail.gmail.com</a>.<br />

--001a114a9686bae80e053e1ca664--

.

On Wednesday 05 October 2016 13:40:20 Domen Vrankar wrote:
> > > > Structured Bindings would be acceptable if, like scripting languages,
> >
> > we
> >
> > > > didn't have anything else to work with.
> > > >
> > > > But we do: We can return a struct.
> > >
> > > Structured bindings work with structs as well. If you think structured
> > > bindings mean
> > > you must return a tuple, you're mistaken.
> >
> > Yes, I know that. But if I return a struct with proper names, I don't
> > need SB
> > to handle it. Indeed, it would be counter-productive to have to find
> > names for
> > SB if can access the names the implementor chose with C-space in my IDE
> > from
> > the auto variable that stores the return type.
>
> So you're saying that returning a structure with error status and result or
> multiple results of which you only need one or two (reason being for eg.
> cheaper to return all at once - due to for e.g. web service call or complex
> processing - than request one by one on need to basis) you would still
> prefer dragging the entire structure around giving the feeling that your
> code has more dependencies than it actually does? Pattern matching would
> probably be better for some cases but it's sometimes nice to have a simpler
> tool handy.

One of us is not underatanding SB correctly, or I don't understand you. SB
stores the whole struct, too, it just defines local aliases to the member of
the struct (or tuple, or pair, or ...).

> > > > I fear Structured Bindings will lead to an explosion of *really* bad
> >
> > API
> >
> > > > that returns std::pair or std::tuple when it should return a small
> > > > struct with
> > >
> > > C++ programmers are not idiots.
> >
> > C++ programmers are humans, though.
> >
> > We all make mistakes. Even Alex Stepanov did. The art is to not repeat
> > them.
>
> This sounds like an argument for not having templates, pointers,
> exceptions, probably even references or any other feature for that matter.

No, it sounds like and argument for checking a feature for how easy it is to
use correctly (SB: very easy) and how hard it is to use incorrectly (SB: very
easy, too), and how much new expressiveness it enables (SB: none(?)).

I see references to pattern matching everywhere I look for SB, and maybe PM
will add more expressiveness, but then let's wait for PM and not add SB, which
does not add enough expressiveness to warrant the drawbacks. SB _is_ touted as
a way to paper over APIs that trade in tuples and pairs. And for that, IMHO,
it is too large a sword for too small a Gordian Knot. If there are other use-
cases, they were notably absent from P0144r2.

> I have ideas on where to use this feature but like with all other features
> it'd be pretty odd to sprinkle it around the code just because I can and
> make odd library apis. Good, poor and all in between designs are already
> present so I doubt that this feature will change that too much but I might
> be wrong :)

And *that* sounds like a call to not pay attention to how a feature can be
abused, because you can abuse any feature. :)

Thanks,
Marc

--
Marc Mutz <marc.mutz@kdab.com> | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - Qt, C++ and OpenGL Experts

.

On 5 October 2016 at 14:00, Marc Mutz <marc.mutz@kdab.com> wrote:
> On Wednesday 05 October 2016 12:40:38 Ville Voutilainen wrote:
>> On 5 October 2016 at 13:38, Marc Mutz <marc.mutz@kdab.com> wrote:
>> > In conjunction with auto deduction, the caller choosing the names means
>> > that the code becomes brittle in the face of changes to the return type,
>> > e.g. when reordering fields to fill padding holes.
>>
>> There have been discussions about that, especially about fields change
>> their types.
>
> And? What was the outcome?

We'll see after the Issaquah meeting. There's an NB comment about it,
I can probably
follow it up with a paper.

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUZquqR8a5-Dbz2FrXS3jrkgZjY_tAxP--Y9TE0p5d%2Bg3w%40mail.gmail.com.

.

--001a114129222997cb053e1dea69
Content-Type: text/plain; charset=UTF-8

On Wed, Oct 5, 2016 at 12:38 PM, Marc Mutz <marc.mutz@kdab.com> wrote:

> The reaons it's horrible, is because it reverses the C++ principle that
the implementor of a library should have to do the work, not the user.

There is no such principle. Because what you say is impossible. A user of a
library always has to do some work to use the library.

What you probably wanted to say is that the library should do something
that reduces the amount of work done by the prospective user of the library
compared to the amount of work required without the library. But then this
statement is trivial, because no one will use a library the use of which
requires more work than its non-use.

> It reverses the principle by requiring the *caller* to choose the names
of the values returned, when it should be the implementor of the function
who chooses the names.

If there is a "horrible" library that makes coming up with good names, and
typing them, an effort outweighing the utility of the library, it will have
to evolve or die.

> In conjunction with auto deduction, the caller choosing the names means
that the code becomes brittle in the face of changes to the return type,
e.g. when reordering fields to fill padding holes.

That is a valid point, but a very similar problem exists with functions
accepting multiple arguments. One can easily come up with horrible
(contrived) examples, but, practically, I do not think this is a major
issue.

Cheers,
V.

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg3ByaVnodRBz06ez4CBH3CzC6r3OJJbh3oyUp5r%3DwNRig%40mail.gmail.com.

--001a114129222997cb053e1dea69
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On W=
ed, Oct 5, 2016 at 12:38 PM, Marc Mutz <span dir=3D"ltr">&lt;<a href=3D"mai=
lto:marc.mutz@kdab.com" target=3D"_blank">marc.mutz@kdab.com</a>&gt;</span>=
 wrote:<br><div><br></div><div>&gt; The reaons it&#39;s horrible, is becaus=
e it reverses the C++ principle that the implementor of a library should ha=
ve to do the work, not the user.</div><div><br></div><div>There is no such =
principle. Because what you say is impossible. A user of a library always h=
as to do some work to use the library.</div><div><br></div><div>What you pr=
obably wanted to say is that the library should do something that reduces t=
he amount of work done by the prospective user of the library compared to t=
he amount of work required without the library. But then this statement is =
trivial, because no one will use a library the use of which requires more w=
ork than its non-use.</div><div><br></div><div>&gt; It reverses the princip=
le by requiring the *caller* to choose the names of the values returned, wh=
en it should be the implementor of the function who chooses the names.<br><=
/div><div><br></div><div>If there is a &quot;horrible&quot; library that ma=
kes coming up with good names, and typing them, an effort outweighing the u=
tility of the library, it will have to evolve or die.</div><div><br></div><=
div>&gt; In conjunction with auto deduction, the caller choosing the names =
means that the code becomes brittle in the face of changes to the return ty=
pe, e.g. when reordering fields to fill padding holes.</div><div><br></div>=
<div>That is a valid point, but a very similar problem exists with function=
s accepting multiple arguments. One can easily come up with horrible (contr=
ived) examples, but, practically, I do not think this is a major issue.</di=
v><div><br></div><div>Cheers,</div><div>V.</div></div></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAA7YVg3ByaVnodRBz06ez4CBH3CzC6r3OJJb=
h3oyUp5r%3DwNRig%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg3ByaVnod=
RBz06ez4CBH3CzC6r3OJJbh3oyUp5r%3DwNRig%40mail.gmail.com</a>.<br />

--001a114129222997cb053e1dea69--

.

------=_Part_4413_768177591.1475675373607
Content-Type: multipart/alternative;
 boundary="----=_Part_4414_191914130.1475675373607"

------=_Part_4414_191914130.1475675373607
Content-Type: text/plain; charset=UTF-8

On Wednesday, October 5, 2016 at 8:09:43 AM UTC-4, Marc Mutz wrote:
>
> On Wednesday 05 October 2016 13:40:20 Domen Vrankar wrote:
> > So you're saying that returning a structure with error status and result
> or
> > multiple results of which you only need one or two (reason being for eg.
> > cheaper to return all at once - due to for e.g. web service call or
> complex
> > processing - than request one by one on need to basis) you would still
> > prefer dragging the entire structure around giving the feeling that your
> > code has more dependencies than it actually does?
>
> One of us is not underatanding SB correctly, or I don't understand you. SB
> stores the whole struct, too, it just defines local aliases to the member
> of
> the struct (or tuple, or pair, or ...).
>

Only if you say that you want references, using "auto &" or "auto &&".  If
you use "auto", you just get copies.


   - If the *assignment-expression* is a prvalue, *e* is an xvalue that
   designates a temporary object copy-initialized from the
   *assignment-expression*. The lifetime of the temporary ends immediately
   after the last variable declaration (see below) if no & follows the
   *decl-specifier-seq* in the decomposition declaration, and is extended
   as usual (12.2 [class.temporary] otherwise.

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/073a7698-1388-4858-b6fa-b2b62a4fb6f1%40isocpp.org.

------=_Part_4414_191914130.1475675373607
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Wednesday, October 5, 2016 at 8:09:43 AM UTC-4, Marc Mu=
tz wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: =
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Wednesday 05 Octob=
er 2016 13:40:20 Domen Vrankar wrote:
<br>&gt; So you&#39;re saying that returning a structure with error status =
and result or
<br>&gt; multiple results of which you only need one or two (reason being f=
or eg.
<br>&gt; cheaper to return all at once - due to for e.g. web service call o=
r complex
<br>&gt; processing - than request one by one on need to basis) you would s=
till
<br>&gt; prefer dragging the entire structure around giving the feeling tha=
t your
<br>&gt; code has more dependencies than it actually does?<br><br>One of us=
 is not underatanding SB correctly, or I don&#39;t understand you. SB=20
<br>stores the whole struct, too, it just defines local aliases to the memb=
er of=20
<br>the struct (or tuple, or pair, or ...).
<br></blockquote><div><br></div><div>Only if you say that you want referenc=
es, using &quot;auto &amp;&quot; or &quot;auto &amp;&amp;&quot;. =C2=A0If y=
ou use &quot;auto&quot;, you just get copies.</div><div><br></div><div><ul =
style=3D"color: rgb(0, 0, 0); font-family: Times; font-size: medium; font-w=
eight: bold;"><li>If the=C2=A0<em>assignment-expression</em>=C2=A0is a prva=
lue,=C2=A0<em>e</em>=C2=A0is an xvalue that designates a temporary object c=
opy-initialized from the=C2=A0<em>assignment-expression</em>. The lifetime =
of the temporary ends immediately after the last variable declaration (see =
below) if no=C2=A0<code>&amp;</code>=C2=A0follows the=C2=A0<em>decl-specifi=
er-seq</em>=C2=A0in the decomposition declaration, and is extended as usual=
 (12.2 [class.temporary] otherwise.</li></ul></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/073a7698-1388-4858-b6fa-b2b62a4fb6f1%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/073a7698-1388-4858-b6fa-b2b62a4fb6f1=
%40isocpp.org</a>.<br />

------=_Part_4414_191914130.1475675373607--

------=_Part_4413_768177591.1475675373607--

.

On 5 October 2016 at 16:49, Greg Marr <gregmmarr@gmail.com> wrote:
> On Wednesday, October 5, 2016 at 8:09:43 AM UTC-4, Marc Mutz wrote:
>>
>> On Wednesday 05 October 2016 13:40:20 Domen Vrankar wrote:
>> > So you're saying that returning a structure with error status and result
>> > or
>> > multiple results of which you only need one or two (reason being for eg.
>> > cheaper to return all at once - due to for e.g. web service call or
>> > complex
>> > processing - than request one by one on need to basis) you would still
>> > prefer dragging the entire structure around giving the feeling that your
>> > code has more dependencies than it actually does?
>>
>> One of us is not underatanding SB correctly, or I don't understand you. SB
>> stores the whole struct, too, it just defines local aliases to the member
>> of
>> the struct (or tuple, or pair, or ...).
>
>
> Only if you say that you want references, using "auto &" or "auto &&".  If
> you use "auto", you just get copies.


You get a copy of the whole struct, not copies of individual bindings.

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUZwZLgNW6-XjHaZO%2B-aPa7AsA8EsHO9Vbf%3Dx%2BFHe-GL-Q%40mail.gmail.com.

.

I think you overestimate the likelihood for problems and underestimate
the convenience offered. The technical points you made were (of course)
considered, repeatedly and seriously.

Yes, you can accidentally reverse the order of naming, just as you can
for function arguments. If the members/arguments are of the same type,
the consequences can be very bad. That's why I don't recommend
interfaces with multiple consecutive arguments of the same type.

You already have the equivalent problems with return types that are
pairs and tuples, and if you don't like structured binding, don't use
it. That's easier done than the equivalent advice for pairs and tuples.

I don't see the problems you outline becoming a major problem, but I do
see the convenience as significant. There is always a balance to be
struck between safety and convenience. Note that languages with a heavy
emphasis on safety tend not to be used for general programming (most
programmers don't like them).


On 10/5/2016 6:38 AM, Marc Mutz wrote:
> Hi Herb, Bjarne, Gabriel,
>
> I heard about Structured Bindings for the first time at CppCon this year, and
> I'd like to raise my concerns, esp. since half of the panel was crazy about
> them.
>
> I strongly believe that the premise that returning std::tuple from functions
> to solve the multiple-return-types problem is good practice, is fundamentally
> wrong.
>
> It is not good in any sense of the word. It is horrible. Indeed, it is so
> horrible that you felt inclined to add a new language feature just to make it
> bearable.
>
> The reaons it's horrible, is because it reverses the C++ principle that the
> implementor of a library should have to do the work, not the user.
>
> It reverses the principle by requiring the *caller* to choose the names of the
> values returned, when it should be the implementor of the function who chooses
> the names.
>
> In conjunction with auto deduction, the caller choosing the names means that
> the code becomes brittle in the face of changes to the return type, e.g. when
> reordering fields to fill padding holes.
>
> Structured Bindings would be acceptable if, like scripting languages, we
> didn't have anything else to work with.
>
> But we do: We can return a struct.
>
> IMHO, the correct solution to the multiple return value problem is to return a
> struct with properly named fields, not a pair and not a tuple.
>
> I fear Structured Bindings will lead to an explosion of *really* bad API that
> returns std::pair or std::tuple when it should return a small struct with
> well-named data members instead, because a) the implementor couldn't be
> bothered to pick good names for a return struct, and b) tuples can be defined
> on the fly, in the function declaration, whereas structs can not.
>
> I believe there's a proposal for allowing to define structs in function
> declarations already, but I failed to find it.
>
> Consider:
>
>     std::map::insert(...) -> std::pair<iterator, bool>
>
> or the other way around, I can never remember, which is a problem that
> structured bindings don't solve for me. Yes, in this case using the iterator
> as a boolean will fail, but what about algorithms that return multiple
> iterators? If you get the order wrong, then you have a bug.
>
> No, map::insert() should have returned a
>
>     struct { iterator iterator; bool inserted; };
>
> so one could say:
>
>     if (map.insert(...).inserted)
>
> or
>
>     auto result = map.insert(...)
>     if (result.inserted)
>
> To summarise: I feel that Structured Bindings are too easy to use incorrectly,
> because they put the burden of choosing a name for the fields of a return
> value on the caller, instead of the implementor, of the function. I'd like to
> see the pattern to return structs from functions strengthened, not the anti-
> pattern of returning pairs and tuples.
>
> I therefore hope that I can persuade you to reconsider adding Structured
> Bindings to C++17.
>
> Thanks,
> Marc
>

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/38e94531-5370-450f-f33d-331c81d8f91f%40Stroustrup.com.

.

> I heard about Structured Bindings for the first time at CppCon this year,=
 and I'd
> like to raise my concerns, esp. since half of the panel was crazy about t=
hem.

Thanks for your interest! Did you read the design paper? It answers many of=
 these questions.


> The reaons it's horrible,=20

Note that you're making a strong value judgment about something you heard a=
bout two weeks ago. You're coming into a design discussion that has been di=
scussed in depth at multiple meetings for nearly a year, and while new info=
rmation is welcome it's always good to enter a discussion-in-progress by tr=
eading lightly (e.g., start by asking whether something has been considered=
). Especially when "half a panel" of people who have been in the deep desig=
n discussions and understand the feature like it a lot. :)

> is because it reverses the C++ principle that the
> implementor of a library should have to do the work, not the user.
>=20
> It reverses the principle by requiring the *caller* to choose the names o=
f the
> values returned,=20

The caller always chooses the name of a returned value in their scope:

 auto my_name =3D f();

SB is just giving them a way to gives names to the individual components if=
 they want to work with them directly, instead of a name to the whole compo=
site entity:

 auto [my_name_1, my_name_2] =3D f();


> when it should be the implementor of the function who
> chooses the names.

You can have your cake and eat it too, because SB works with structs:

> IMHO, the correct solution to the multiple return value problem is to ret=
urn a
> struct with properly named fields, not a pair and not a tuple.

(Actually IMO the correct solution is multiple return values. Returning a s=
truct is our current workaround, the closest approximation in today's langu=
age.)

That's fine, you can do that, and it works fine with SB. . Here's an exampl=
e from my own recent gcpp library, https://github.com/hsutter/gcpp:

 struct contains_info_ret {
  gpage_find_result found;
  std::size_t location;
  std::size_t start_location;
 };
 contains_info_ret
 contains_info(gsl::not_null<const byte*> p) const noexcept;

The only thing that C++ doesn't currently let you do is to omit the "; cont=
ains_info_ret" in the middle, to declare a struct in the position of a retu=
rn value. From time to time people suggest allowing that; I wouldn't be sur=
prised to see it proposed in the future. (I would like to see that proposal=
.. I would even more like to see a multiple return values proposal.)

But SB works fine with this, because it allows the caller to write both thi=
s:

 auto info =3D page.contains_info(ptr);
 if (info.found =3D=3D /*...*/) {
  use(info.location, info.start_location);
 }

and this:

 auto [found, offset, start] info =3D page.contains_info(ptr);
 if (found =3D=3D /*...*/) {
  use(offset, start);
 }

Returning a struct should be thought of as the callee returning "default" n=
ames for the caller to use. With SB, the caller has a choice and can either=
 use the default names or else provide more meaningful names if they want t=
o; it doesn't hurt your preference for returning a struct at all, in fact i=
t cooperates very well with that -- and that's not an accident, it's by des=
ign since the very first design paper.

Herb



> -----Original Message-----
> From: marc@kdab.com [mailto:marc@kdab.com] On Behalf Of Marc Mutz
> Sent: Wednesday, October 5, 2016 3:38 AM
> To: Herb Sutter <hsutter@microsoft.com>; bjarne@stroustrup.com; Gabriel
> Dos Reis <gdr@microsoft.com>
> Cc: std-proposals@isocpp.org
> Subject: A plea to reconsider adding Structured Bindings to language
>=20
> Hi Herb, Bjarne, Gabriel,
>=20
> I heard about Structured Bindings for the first time at CppCon this year,=
 and I'd
> like to raise my concerns, esp. since half of the panel was crazy about t=
hem.
>=20
> I strongly believe that the premise that returning std::tuple from functi=
ons to
> solve the multiple-return-types problem is good practice, is fundamentall=
y
> wrong.
>=20
> It is not good in any sense of the word. It is horrible. Indeed, it is so=
 horrible that
> you felt inclined to add a new language feature just to make it bearable.
>=20
> The reaons it's horrible, is because it reverses the C++ principle that t=
he
> implementor of a library should have to do the work, not the user.
>=20
> It reverses the principle by requiring the *caller* to choose the names o=
f the
> values returned, when it should be the implementor of the function who
> chooses the names.
>=20
> In conjunction with auto deduction, the caller choosing the names means t=
hat
> the code becomes brittle in the face of changes to the return type, e.g. =
when
> reordering fields to fill padding holes.
>=20
> Structured Bindings would be acceptable if, like scripting languages, we =
didn't
> have anything else to work with.
>=20
> But we do: We can return a struct.
>=20
> IMHO, the correct solution to the multiple return value problem is to ret=
urn a
> struct with properly named fields, not a pair and not a tuple.
>=20
> I fear Structured Bindings will lead to an explosion of *really* bad API =
that
> returns std::pair or std::tuple when it should return a small struct with=
 well-
> named data members instead, because a) the implementor couldn't be bother=
ed
> to pick good names for a return struct, and b) tuples can be defined on t=
he fly, in
> the function declaration, whereas structs can not.
>=20
> I believe there's a proposal for allowing to define structs in function d=
eclarations
> already, but I failed to find it.
>=20
> Consider:
>=20
>    std::map::insert(...) -> std::pair<iterator, bool>
>=20
> or the other way around, I can never remember, which is a problem that
> structured bindings don't solve for me. Yes, in this case using the itera=
tor as a
> boolean will fail, but what about algorithms that return multiple iterato=
rs? If you
> get the order wrong, then you have a bug.
>=20
> No, map::insert() should have returned a
>=20
>    struct { iterator iterator; bool inserted; };
>=20
> so one could say:
>=20
>    if (map.insert(...).inserted)
>=20
> or
>=20
>    auto result =3D map.insert(...)
>    if (result.inserted)
>=20
> To summarise: I feel that Structured Bindings are too easy to use incorre=
ctly,
> because they put the burden of choosing a name for the fields of a return=
 value
> on the caller, instead of the implementor, of the function. I'd like to s=
ee the
> pattern to return structs from functions strengthened, not the anti- patt=
ern of
> returning pairs and tuples.
>=20
> I therefore hope that I can persuade you to reconsider adding Structured
> Bindings to C++17.
>=20
> Thanks,
> Marc
>=20
> --
> Marc Mutz <marc.mutz@kdab.com> | Senior Software Engineer KDAB
> (Deutschland) GmbH & Co.KG, a KDAB Group Company
> Tel: +49-30-521325470
> KDAB - Qt, C++ and OpenGL Experts

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/BY2PR0301MB207067A62039FBA165EB7AEFB8C40%40BY2PR=
0301MB2070.namprd03.prod.outlook.com.

.

------=_Part_4423_380988592.1475677202981
Content-Type: multipart/alternative;
 boundary="----=_Part_4424_921199171.1475677202981"

------=_Part_4424_921199171.1475677202981
Content-Type: text/plain; charset=UTF-8

On Wednesday, October 5, 2016 at 10:07:29 AM UTC-4, Ville Voutilainen wrote:
>
> On 5 October 2016 at 16:49, Greg Marr <greg...@gmail.com <javascript:>>
> wrote:
> > On Wednesday, October 5, 2016 at 8:09:43 AM UTC-4, Marc Mutz wrote:
> >>
> >> On Wednesday 05 October 2016 13:40:20 Domen Vrankar wrote:
> >> > So you're saying that returning a structure with error status and
> result
> >> > or
> >> > multiple results of which you only need one or two (reason being for
> eg.
> >> > cheaper to return all at once - due to for e.g. web service call or
> >> > complex
> >> > processing - than request one by one on need to basis) you would
> still
> >> > prefer dragging the entire structure around giving the feeling that
> your
> >> > code has more dependencies than it actually does?
> >>
> >> One of us is not underatanding SB correctly, or I don't understand you.
> SB
> >> stores the whole struct, too, it just defines local aliases to the
> member
> >> of
> >> the struct (or tuple, or pair, or ...).
> >
> >
> > Only if you say that you want references, using "auto &" or "auto &&".
>  If
> > you use "auto", you just get copies.
>
> You get a copy of the whole struct, not copies of individual bindings.
>

That's not what's described in the paper.  Has it changed
since https://isocpp.org/files/papers/p0217r0.html ?
The binding results in individual variables, and if they're copies of the
values from the struct, there is no reason to keep the original struct
around.

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/bdc55144-9d72-4661-958c-3582a535b579%40isocpp.org.

------=_Part_4424_921199171.1475677202981
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Wednesday, October 5, 2016 at 10:07:29 AM UTC-4, Ville =
Voutilainen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 5 October=
 2016 at 16:49, Greg Marr &lt;<a href=3D"javascript:" target=3D"_blank" gdf=
-obfuscated-mailto=3D"T2-luHV4BwAJ" rel=3D"nofollow" onmousedown=3D"this.hr=
ef=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javasc=
ript:&#39;;return true;">greg...@gmail.com</a>&gt; wrote:
<br>&gt; On Wednesday, October 5, 2016 at 8:09:43 AM UTC-4, Marc Mutz wrote=
:
<br>&gt;&gt;
<br>&gt;&gt; On Wednesday 05 October 2016 13:40:20 Domen Vrankar wrote:
<br>&gt;&gt; &gt; So you&#39;re saying that returning a structure with erro=
r status and result
<br>&gt;&gt; &gt; or
<br>&gt;&gt; &gt; multiple results of which you only need one or two (reaso=
n being for eg.
<br>&gt;&gt; &gt; cheaper to return all at once - due to for e.g. web servi=
ce call or
<br>&gt;&gt; &gt; complex
<br>&gt;&gt; &gt; processing - than request one by one on need to basis) yo=
u would still
<br>&gt;&gt; &gt; prefer dragging the entire structure around giving the fe=
eling that your
<br>&gt;&gt; &gt; code has more dependencies than it actually does?
<br>&gt;&gt;
<br>&gt;&gt; One of us is not underatanding SB correctly, or I don&#39;t un=
derstand you. SB
<br>&gt;&gt; stores the whole struct, too, it just defines local aliases to=
 the member
<br>&gt;&gt; of
<br>&gt;&gt; the struct (or tuple, or pair, or ...).
<br>&gt;
<br>&gt;
<br>&gt; Only if you say that you want references, using &quot;auto &amp;&q=
uot; or &quot;auto &amp;&amp;&quot;. =C2=A0If
<br>&gt; you use &quot;auto&quot;, you just get copies.
<br><br>You get a copy of the whole struct, not copies of individual bindin=
gs.
<br></blockquote><div><br></div><div>That&#39;s not what&#39;s described in=
 the paper. =C2=A0Has it changed since=C2=A0https://isocpp.org/files/papers=
/p0217r0.html ?</div><div>The binding results in individual variables, and =
if they&#39;re copies of the values from the struct, there is no reason to =
keep the original struct around.</div><div><br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/bdc55144-9d72-4661-958c-3582a535b579%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/bdc55144-9d72-4661-958c-3582a535b579=
%40isocpp.org</a>.<br />

------=_Part_4424_921199171.1475677202981--

------=_Part_4423_380988592.1475677202981--

.

------=_Part_4592_2093020881.1475677399661
Content-Type: multipart/alternative;
 boundary="----=_Part_4593_1195114652.1475677399661"

------=_Part_4593_1195114652.1475677399661
Content-Type: text/plain; charset=UTF-8

On Wednesday, October 5, 2016 at 10:14:05 AM UTC-4, Herb Sutter wrote:
>
> But SB works fine with this, because it allows the caller to write both
> this:
>
>         auto info = page.contains_info(ptr);
>         if (info.found == /*...*/) {
>                 use(info.location, info.start_location);
>         }
>
> and this:
>
>         auto [found, offset, start] info = page.contains_info(ptr);
>         if (found == /*...*/) {
>                 use(offset, start);
>         }
>

Is the "info" in the first line of the second example a typo?  It doesn't
seem like it belongs there.

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/e6745f0f-3004-4348-ad1f-e3be259cd19a%40isocpp.org.

------=_Part_4593_1195114652.1475677399661
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Wednesday, October 5, 2016 at 10:14:05 AM UTC-4, Herb S=
utter wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">But SB works fine =
with this, because it allows the caller to write both this:
<br>
<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0auto info =3D page.cont=
ains_info(ptr);
<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0if (info.found =3D=3D /=
*...*/) {
<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0use(info.<wbr>location, info.start_location);
<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0}
<br>
<br>and this:
<br>
<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0auto [found, offset, st=
art] info =3D page.contains_info(ptr);
<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0if (found =3D=3D /*...*=
/) {
<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0use(offset, start);
<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0}
<br></blockquote><div><br></div><div>Is the &quot;info&quot; in the first l=
ine of the second example a typo? =C2=A0It doesn&#39;t seem like it belongs=
 there.</div><div><br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/e6745f0f-3004-4348-ad1f-e3be259cd19a%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/e6745f0f-3004-4348-ad1f-e3be259cd19a=
%40isocpp.org</a>.<br />

------=_Part_4593_1195114652.1475677399661--

------=_Part_4592_2093020881.1475677399661--

.

On 5 October 2016 at 17:20, Greg Marr <gregmmarr@gmail.com> wrote:
>> > Only if you say that you want references, using "auto &" or "auto &&".
>> > If
>> > you use "auto", you just get copies.
>>
>> You get a copy of the whole struct, not copies of individual bindings.
>
>
> That's not what's described in the paper.  Has it changed since

That's what the wording of the facility does, and what the clang
implementation does.

> https://isocpp.org/files/papers/p0217r0.html ?

See http://open-std.org/JTC1/SC22/WG21/docs/papers/2016/p0217r1.html


> The binding results in individual variables, and if they're copies of the
> values from the struct, there is no reason to keep the original struct
> around.

Except that yes there is, because if the fields depend on each other,
copying them individually
can break invariants.

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUb_y9r3C99s_Sqeh7dxCkqeE-j9fCP_DbH0S7%2Bip_pF5g%40mail.gmail.com.

.

------=_Part_4481_1268614287.1475678167472
Content-Type: multipart/alternative;
 boundary="----=_Part_4482_242691810.1475678167472"

------=_Part_4482_242691810.1475678167472
Content-Type: text/plain; charset=UTF-8

On Wednesday, October 5, 2016 at 10:26:09 AM UTC-4, Ville Voutilainen wrote:
>
> On 5 October 2016 at 17:20, Greg Marr <greg...@gmail.com <javascript:>>
> wrote:
> >> > Only if you say that you want references, using "auto &" or "auto
> &&".
> >> > If
> >> > you use "auto", you just get copies.
> >>
> >> You get a copy of the whole struct, not copies of individual bindings.
> >
> >
> > That's not what's described in the paper.  Has it changed since
>
> That's what the wording of the facility does, and what the clang
> implementation does.
>
> > https://isocpp.org/files/papers/p0217r0.html ?
>
> See http://open-std.org/JTC1/SC22/WG21/docs/papers/2016/p0217r1.html
>

Thanks.  The relevant parts of that paper that significantly change this
feature from the one I referenced before:


That paper incorporates feedback from the EWG session in Jacksonville as
follows:




   - introduced variables are, in all cases, references to the value of the
      initializer
      - the cv-qualifiers and ref-qualifier of the decomposition
      declaration are applied to the reference introduced for the initializer,
      not for the individual member aliases


--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/590c1dd8-e59f-48d3-9e66-bb7165d1b8b3%40isocpp.org.

------=_Part_4482_242691810.1475678167472
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Wednesday, October 5, 2016 at 10:26:09 AM UTC-4, Ville =
Voutilainen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 5 October=
 2016 at 17:20, Greg Marr &lt;<a href=3D"javascript:" target=3D"_blank" gdf=
-obfuscated-mailto=3D"gbw7lnp5BwAJ" rel=3D"nofollow" onmousedown=3D"this.hr=
ef=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javasc=
ript:&#39;;return true;">greg...@gmail.com</a>&gt; wrote:
<br>&gt;&gt; &gt; Only if you say that you want references, using &quot;aut=
o &amp;&quot; or &quot;auto &amp;&amp;&quot;.
<br>&gt;&gt; &gt; If
<br>&gt;&gt; &gt; you use &quot;auto&quot;, you just get copies.
<br>&gt;&gt;
<br>&gt;&gt; You get a copy of the whole struct, not copies of individual b=
indings.
<br>&gt;
<br>&gt;
<br>&gt; That&#39;s not what&#39;s described in the paper. =C2=A0Has it cha=
nged since
<br>
<br>That&#39;s what the wording of the facility does, and what the clang
<br>implementation does.
<br>
<br>&gt; <a href=3D"https://isocpp.org/files/papers/p0217r0.html" target=3D=
"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;https://www.googl=
e.com/url?q\x3dhttps%3A%2F%2Fisocpp.org%2Ffiles%2Fpapers%2Fp0217r0.html\x26=
sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEQns86qWfphKC8OVJo1A5cTrZfGQ&#39;;retu=
rn true;" onclick=3D"this.href=3D&#39;https://www.google.com/url?q\x3dhttps=
%3A%2F%2Fisocpp.org%2Ffiles%2Fpapers%2Fp0217r0.html\x26sa\x3dD\x26sntz\x3d1=
\x26usg\x3dAFQjCNEQns86qWfphKC8OVJo1A5cTrZfGQ&#39;;return true;">https://is=
ocpp.org/files/<wbr>papers/p0217r0.html</a> ?
<br>
<br>See <a href=3D"http://open-std.org/JTC1/SC22/WG21/docs/papers/2016/p021=
7r1.html" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#3=
9;http://www.google.com/url?q\x3dhttp%3A%2F%2Fopen-std.org%2FJTC1%2FSC22%2F=
WG21%2Fdocs%2Fpapers%2F2016%2Fp0217r1.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x=
3dAFQjCNGrJeex8qwFkuyxQj5N5i3HSnfECw&#39;;return true;" onclick=3D"this.hre=
f=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fopen-std.org%2FJTC1%2F=
SC22%2FWG21%2Fdocs%2Fpapers%2F2016%2Fp0217r1.html\x26sa\x3dD\x26sntz\x3d1\x=
26usg\x3dAFQjCNGrJeex8qwFkuyxQj5N5i3HSnfECw&#39;;return true;">http://open-=
std.org/JTC1/SC22/<wbr>WG21/docs/papers/2016/p0217r1.<wbr>html</a>
<br></blockquote><div><br></div><div>Thanks. =C2=A0The relevant parts of th=
at paper that significantly change this feature from the one I referenced b=
efore:</div><div>=C2=A0</div><blockquote style=3D"margin: 0 0 0 40px; borde=
r: none; padding: 0px;"><div><span style=3D"color: rgb(0, 0, 0); font-famil=
y: Times; font-size: medium;">That paper incorporates feedback from the EWG=
 session in Jacksonville as follows:</span></div></blockquote><div><ul styl=
e=3D"color: rgb(0, 0, 0); font-family: Times; font-size: medium;"></ul></di=
v><div><ul style=3D"color: rgb(0, 0, 0); font-family: Times; font-size: med=
ium;"><ul><li>introduced variables are, in all cases, references to the val=
ue of the initializer</li><li>the cv-qualifiers and ref-qualifier of the de=
composition declaration are applied to the reference introduced for the ini=
tializer, not for the individual member aliases</li></ul></ul></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/590c1dd8-e59f-48d3-9e66-bb7165d1b8b3%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/590c1dd8-e59f-48d3-9e66-bb7165d1b8b3=
%40isocpp.org</a>.<br />

------=_Part_4482_242691810.1475678167472--

------=_Part_4481_1268614287.1475678167472--

.

------=_Part_457_1638641246.1475684084162
Content-Type: multipart/alternative;
 boundary="----=_Part_458_187217477.1475684084163"

------=_Part_458_187217477.1475684084163
Content-Type: text/plain; charset=UTF-8

On Wednesday, October 5, 2016 at 6:36:35 AM UTC-4, Marc Mutz wrote:
>
> Hi Herb, Bjarne, Gabriel,
>
> I heard about Structured Bindings for the first time at CppCon this year,
> and
> I'd like to raise my concerns, esp. since half of the panel was crazy
> about
> them.
>
> I strongly believe that the premise that returning std::tuple from
> functions
> to solve the multiple-return-types problem is good practice, is
> fundamentally
> wrong.
>
> It is not good in any sense of the word. It is horrible. Indeed, it is so
> horrible that you felt inclined to add a new language feature just to make
> it
> bearable.
>
> The reaons it's horrible, is because it reverses the C++ principle that
> the
> implementor of a library should have to do the work, not the user.
>
> It reverses the principle by requiring the *caller* to choose the names of
> the
> values returned, when it should be the implementor of the function who
> chooses
> the names.
>
> In conjunction with auto deduction, the caller choosing the names means
> that
> the code becomes brittle in the face of changes to the return type, e.g.
> when
> reordering fields to fill padding holes.
>

Structured binding is hardly the first C++ feature that makes struct field
ordering important. Aggregate initialization did that long before. If you
"reorder fields to fill padding holes" on an interface structure, then
you've broken any code that used aggregate initialization on that type.

Now yes, you can fix that by giving that type constructors that mimic the
previous ordering. But then again, you can fix similar changes with
structured binding by giving that type `tuple_size`/etc functions that
mimic the previous ordering as well. So in both cases, we have the tools to
make such changes backwards compatibly.

Structs are *ordered* collections of named objects. Ordering is a
fundamental part of a struct, and structured binding is not the only C++
feature that relies on the order of a struct's members.

Structured Bindings would be acceptable if, like scripting languages, we
> didn't have anything else to work with.
>
> But we do: We can return a struct.
>
> IMHO, the correct solution to the multiple return value problem is to
> return a
> struct with properly named fields, not a pair and not a tuple.
>

Then let us consider the question of "properly named fields". "Properly
named" *for whom*, exactly?

The function returns values that have some meaning. But the caller gives
those values added meaning as well. Consider your `map::insert` code, where
you return a struct of two values. One is called "inserted" and the other
is called "iterator".

Well... what does "iterator" *mean*? To `map::insert`, it merely means the
iterator where the item is inserted. But that item that was inserted has a
semantic meaning to the caller of `map::insert`. Therefore, the iterator
where that item was inserted also has a semantic meaning: the position of
that item.

A meaning which is not reflected in the generic "result.iterator" name you
give it. This means that the person reading the calling code has to
remember what `map::insert` returns, as well as the semantic meaning of
what was passed to `map::insert`.

Structured binding allows the calling code to impose semantic meaning to
such things. Meaning that the function returning those values cannot
possibly know about.

At its core, this is no different from the ability of functions to give
names to parameters. The caller passes some object that often has a name.
But to the context of the function being called, that object has a semantic
meaning which is different from the one the caller gave it. So the function
gets to give it a meaning which expresses the intent of the code being
called, rather than the intent of the caller.

Why should function return values be any different? The called function
gives these return values one meaning, and the caller can alter that
meaning based on its needs.

I fear Structured Bindings will lead to an explosion of *really* bad API
> that
> returns std::pair or std::tuple when it should return a small struct with
> well-named data members instead, because a) the implementor couldn't be
> bothered to pick good names for a return struct, and b) tuples can be
> defined
> on the fly, in the function declaration, whereas structs can not.
>
> I believe there's a proposal for allowing to define structs in function
> declarations already, but I failed to find it.
>

It's P0222 <http://wg21.link/P0222>. If you read that proposal however, one
of its primary motivations is to work *in tandem with* structured bindings.
It was not designed to work against it, but alongside it.

The idea being that the member names which the anonymous struct uses would
be self-documenting as to their meaning. But the caller can still impose
their own semantic meaning via structured binding, as they see fit. And
that proposal sees as perfectly legitimate.

So returning anonymous structs is not a replacement for structured binding.
We'd still want structured binding even if we could return anonymous
structs.

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/adffa9c0-2c7a-4d98-8fc3-2e787109b858%40isocpp.org.

------=_Part_458_187217477.1475684084163
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Wednesday, October 5, 2016 at 6:36:35 AM UTC-4, Marc Mu=
tz wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: =
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Hi Herb, Bjarne, Gabr=
iel,
<br>
<br>I heard about Structured Bindings for the first time at CppCon this yea=
r, and=20
<br>I&#39;d like to raise my concerns, esp. since half of the panel was cra=
zy about=20
<br>them.
<br>
<br>I strongly believe that the premise that returning std::tuple from func=
tions=20
<br>to solve the multiple-return-types problem is good practice, is fundame=
ntally=20
<br>wrong.
<br>
<br>It is not good in any sense of the word. It is horrible. Indeed, it is =
so=20
<br>horrible that you felt inclined to add a new language feature just to m=
ake it=20
<br>bearable.
<br>
<br>The reaons it&#39;s horrible, is because it reverses the C++ principle =
that the=20
<br>implementor of a library should have to do the work, not the user.
<br>
<br>It reverses the principle by requiring the *caller* to choose the names=
 of the=20
<br>values returned, when it should be the implementor of the function who =
chooses=20
<br>the names.
<br>
<br>In conjunction with auto deduction, the caller choosing the names means=
 that=20
<br>the code becomes brittle in the face of changes to the return type, e.g=
.. when=20
<br>reordering fields to fill padding holes.<br></blockquote><div><br>Struc=
tured binding is hardly the first C++ feature that makes struct field order=
ing important. Aggregate initialization did that long before. If you &quot;=
reorder fields to fill padding holes&quot; on an interface structure, then =
you&#39;ve broken any code that used aggregate initialization on that type.=
<br><br>Now yes, you can fix that by giving that type constructors that mim=
ic the previous ordering. But then again, you can fix similar changes with =
structured binding by giving that type `tuple_size`/etc functions that mimi=
c the previous ordering as well. So in both cases, we have the tools to mak=
e such changes backwards compatibly.<br><br>Structs are <i>ordered</i> coll=
ections of named objects. Ordering is a fundamental part of a struct, and s=
tructured binding is not the only C++ feature that relies on the order of a=
 struct&#39;s members.<br><br></div><blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;">
Structured Bindings would be acceptable if, like scripting languages, we=20
<br>didn&#39;t have anything else to work with.
<br>
<br>But we do: We can return a struct.
<br>
<br>IMHO, the correct solution to the multiple return value problem is to r=
eturn a=20
<br>struct with properly named fields, not a pair and not a tuple.<br></blo=
ckquote><div><br>Then let us consider the question of &quot;properly named =
fields&quot;. &quot;Properly named&quot; <i>for whom</i>, exactly?<br><br>T=
he function returns values that have some meaning. But the caller gives tho=
se values added meaning as well. Consider your `map::insert` code, where yo=
u return a struct of two values. One is called &quot;inserted&quot; and the=
 other is called &quot;iterator&quot;.<br><br>Well... what does &quot;itera=
tor&quot; <i>mean</i>? To `map::insert`, it merely means the iterator where=
 the item is inserted. But that item that was inserted has a semantic meani=
ng to the caller of `map::insert`. Therefore, the iterator where that item =
was inserted also has a semantic meaning: the position of that item.<br><br=
>A meaning which is not reflected in the generic &quot;result.iterator&quot=
; name you give it. This means that the person reading the calling code has=
 to remember what `map::insert` returns, as well as the semantic meaning of=
 what was passed to `map::insert`.<br><br>Structured binding allows the cal=
ling code to impose semantic meaning to such things. Meaning that the funct=
ion returning those values cannot possibly know about.<br><br>At its core, =
this is no different from the ability of functions to give names to paramet=
ers. The caller passes some object that often has a name. But to the contex=
t of the function being called, that object has a semantic meaning which is=
 different from the one the caller gave it. So the function gets to give it=
 a meaning which expresses the intent of the code being called, rather than=
 the intent of the caller.<br><br>Why should function return values be any =
different? The called function gives these return values one meaning, and t=
he caller can alter that meaning based on its needs.<br><br></div><blockquo=
te class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left:=
 1px #ccc solid;padding-left: 1ex;">
I fear Structured Bindings will lead to an explosion of *really* bad API th=
at=20
<br>returns std::pair or std::tuple when it should return a small struct wi=
th=20
<br>well-named data members instead, because a) the implementor couldn&#39;=
t be=20
<br>bothered to pick good names for a return struct, and b) tuples can be d=
efined=20
<br>on the fly, in the function declaration, whereas structs can not.
<br>
<br>I believe there&#39;s a proposal for allowing to define structs in func=
tion=20
<br>declarations already, but I failed to find it.<br></blockquote><div><br=
>It&#39;s <a href=3D"http://wg21.link/P0222">P0222</a>. If you read that pr=
oposal however, one of its primary motivations is to work <i>in tandem with=
</i> structured bindings. It was not designed to work against it, but along=
side it.<br><br>The idea being that the member names which the anonymous st=
ruct uses would be self-documenting as to their meaning. But the caller can=
 still impose their own semantic meaning via structured binding, as they se=
e fit. And that proposal sees as perfectly legitimate.<br><br>So returning =
anonymous structs is not a replacement for structured binding. We&#39;d sti=
ll want structured binding even if we could return anonymous structs.</div>=
</div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/adffa9c0-2c7a-4d98-8fc3-2e787109b858%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/adffa9c0-2c7a-4d98-8fc3-2e787109b858=
%40isocpp.org</a>.<br />

------=_Part_458_187217477.1475684084163--

------=_Part_457_1638641246.1475684084162--

.

This is a multi-part message in MIME format.
--------------B311E0158E739889F70086AA
Content-Type: text/plain; charset=UTF-8; format=flowed



On 10/5/2016 12:14 PM, Nicol Bolas wrote:
> On Wednesday, October 5, 2016 at 6:36:35 AM UTC-4, Marc Mutz wrote:
>
>     Hi Herb, Bjarne, Gabriel,
>     ...
>
>
> Structured binding is hardly the first C++ feature that makes struct
> field ordering important. Aggregate initialization did that long
> before. If you "reorder fields to fill padding holes" on an interface
> structure, then you've broken any code that used aggregate
> initialization on that type.
Good point. It has been like this since 1974 or so.

....

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/03b1942d-6e9d-849f-2dd9-b127bad1854e%40Stroustrup.com.

--------------B311E0158E739889F70086AA
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<html>
  <head>
    <meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type=
">
  </head>
  <body bgcolor=3D"#FFFFFF" text=3D"#000000">
    <p><br>
    </p>
    <br>
    <div class=3D"moz-cite-prefix">On 10/5/2016 12:14 PM, Nicol Bolas
      wrote:<br>
    </div>
    <blockquote
      cite=3D"mid:adffa9c0-2c7a-4d98-8fc3-2e787109b858@isocpp.org"
      type=3D"cite">
      <div dir=3D"ltr">On Wednesday, October 5, 2016 at 6:36:35 AM UTC-4,
        Marc Mutz wrote:
        <blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
          0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Hi Herb,
          Bjarne, Gabriel,
          <br>
          ...<br>
        </blockquote>
        <div><br>
          Structured binding is hardly the first C++ feature that makes
          struct field ordering important. Aggregate initialization did
          that long before. If you "reorder fields to fill padding
          holes" on an interface structure, then you've broken any code
          that used aggregate initialization on that type.<br>
        </div>
      </div>
    </blockquote>
    Good point. It has been like this since 1974 or so.<br>
    <br>
    ...<br>
  </body>
</html>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/03b1942d-6e9d-849f-2dd9-b127bad1854e%=
40Stroustrup.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.goo=
gle.com/a/isocpp.org/d/msgid/std-proposals/03b1942d-6e9d-849f-2dd9-b127bad1=
854e%40Stroustrup.com</a>.<br />

--------------B311E0158E739889F70086AA--

.

--001a1144f170a0f3ec053e26a0b1
Content-Type: text/plain; charset=UTF-8

On Wed, Oct 5, 2016 at 3:38 AM, Marc Mutz <marc.mutz@kdab.com> wrote:
>
> To summarise: I feel that Structured Bindings are too easy to use
> incorrectly,
> because they put the burden of choosing a name for the fields of a return
> value on the caller, instead of the implementor, of the function. I'd like
> to
> see the pattern to return structs from functions strengthened, not the
> anti-
> pattern of returning pairs and tuples.
>

Hi Marc,

People have already addressed your concerns, but you seem to also be
missing one of the key, important reasons why tuples are useful to library
developers -- specifically, they are necessary when the amount and types of
the tuple fields are dependent on template parameters used by a library. In
these cases, a library implementor simply *cannot* "create a struct with
named members". You are mostly arguing that pairs and tuples are often
misused by developers and even by the standard, which is actually a
statement that I agree with, however, tuples are still very necessary in
generic libraries, and users of those libraries can get a lot of benefit
from structured bindings. Structured bindings are also useful not just for
tuples, but also for structs, so your argument based on tuple is a bit
misguided.

For an example of a library that cannot simply create a struct with named
members, consider Boost.Spirit, which is not at all unique in this respect.

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANh8DEnDB0AGhvCCBTpFg1365HxM_6oA2BxDYWb8t6qG4XMDbg%40mail.gmail.com.

--001a1144f170a0f3ec053e26a0b1
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On W=
ed, Oct 5, 2016 at 3:38 AM, Marc Mutz <span dir=3D"ltr">&lt;<a href=3D"mail=
to:marc.mutz@kdab.com" target=3D"_blank">marc.mutz@kdab.com</a>&gt;</span> =
wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l=
eft:1px #ccc solid;padding-left:1ex">
To summarise: I feel that Structured Bindings are too easy to use incorrect=
ly,<br>
because they put the burden of choosing a name for the fields of a return<b=
r>
value on the caller, instead of the implementor, of the function. I&#39;d l=
ike to<br>
see the pattern to return structs from functions strengthened, not the anti=
-<br>
pattern of returning pairs and tuples.<span class=3D"HOEnZb"><font color=3D=
"#888888"><br>
</font></span></blockquote></div><br></div><div class=3D"gmail_extra">Hi Ma=
rc,</div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">Pe=
ople have already addressed your concerns, but you seem to also be missing =
one of the key, important reasons why tuples are useful to library develope=
rs -- specifically, they are necessary when the amount and types of the tup=
le fields are dependent on template parameters used by a library. In these =
cases, a library implementor simply *cannot* &quot;create a struct with nam=
ed members&quot;. You are mostly arguing that pairs and tuples are often mi=
sused by developers and even by the standard, which is actually a statement=
 that I agree with, however, tuples are still very necessary in generic lib=
raries, and users of those libraries can get a lot of benefit from structur=
ed bindings. Structured bindings are also useful not just for tuples, but a=
lso for structs, so your argument based on tuple is a bit misguided.</div><=
div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">For an examp=
le of a library that cannot simply create a struct with named members, cons=
ider Boost.Spirit, which is not at all unique in this respect.</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CANh8DEnDB0AGhvCCBTpFg1365HxM_6oA2BxD=
YWb8t6qG4XMDbg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANh8DEnDB0AGhvCC=
BTpFg1365HxM_6oA2BxDYWb8t6qG4XMDbg%40mail.gmail.com</a>.<br />

--001a1144f170a0f3ec053e26a0b1--

.

(Apologies if this posts twice; the original appears to have gotten lost.)

On 2016-10-05 13:08, Marc Mutz wrote:
> Even with so much effort going into making the Qt 4 API more readable, at
> roughly the same time, this slipped in:
>
>    typedef QPair<double, QColor> QGradientStop;

FWIW, this sort of thing needs to be burned with fire anywhere it
happens. IMHO we need to keep working on the "tuple-like" concept so
that there is *no reason* to write the above instead of:

  struct QGradientStop { double position; QColor color; };

I don't think we're there yet. There are (apparently) still cases where
QPair/std::pair/std::tuple is more useful than a struct. If we can make
that no longer the case, I hope we can stop (ab)using those for cases
that a struct is more appropriate.

--
Matthew

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/ntlgqd%243tk%243%40blaine.gmane.org.

.

(Apologies if this posts twice; the original appears to have gotten lost.)

On 2016-10-05 06:38, Marc Mutz wrote:
> I heard about Structured Bindings for the first time at CppCon this year, and
> I'd like to raise my concerns, esp. since half of the panel was crazy about
> them.
>
> The reaons it's horrible, is because it reverses the C++ principle that the
> implementor of a library should have to do the work, not the user.
>
> It reverses the principle by requiring the *caller* to choose the names of the
> values returned, when it should be the implementor of the function who chooses
> the names.
>
> Structured Bindings would be acceptable if, like scripting languages, we
> didn't have anything else to work with.
>
> But we do: We can return a struct.
>
> IMHO, the correct solution to the multiple return value problem is to return a
> struct with properly named fields, not a pair and not a tuple.
>
> I believe there's a proposal for allowing to define structs in function
> declarations already, but I failed to find it.

You are likely thinking of http://wg21.link/p0222 and
http://wg21.link/p0224. (I still need to merge and dust those off one of
these days...)

I agree that P0222 would be *much* better than returning pair/tuple, but
I also don't have a problem with assignment unpacking. I'm not convinced
that return values are so much more brittle than parameters that they
will make API stability much worse.

(That said, I wouldn't be overly heartbroken if S.B. was held back for a
revision. I'm not convinced that we've solved bitfields adequately.)

--
Matthew

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/ntlgq3%243tk%242%40blaine.gmane.org.

.