map<foo, map<set<bar>, baz>
complicated(...) {
     decltype(return) ret;
     // add stuff to ret
     return try;
}

Instead of repeating the complicated type, refer to it via
decltype(return).  Won't work with deduced return types, of course.

--
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/658f00ff-7a02-7c04-3fcb-6ac7f45b777b%40scylladb.com.

.

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

On Fri, Nov 18, 2016 at 11:01 AM, Avi Kivity <avi@scylladb.com> wrote:

>
> map<foo, map<set<bar>, baz>
> complicated(...) {
>     decltype(return) ret;
>     // add stuff to ret
>     return try;
> }


I like this a lot.

--
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/CANh8DEm42NZAOzbfSteRnk%2BErYhsSzxyg%2BGbtQp3Hm%3DLcZs3WA%40mail.gmail.com.

--001a11439232b85e550541971322
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 F=
ri, Nov 18, 2016 at 11:01 AM, Avi Kivity <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:avi@scylladb.com" target=3D"_blank">avi@scylladb.com</a>&gt;</span> w=
rote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
r-left:1px #ccc solid;padding-left:1ex"><br>
map&lt;foo, map&lt;set&lt;bar&gt;, baz&gt;<br>
complicated(...) {<br>
=C2=A0 =C2=A0 decltype(return) ret;<br>
=C2=A0 =C2=A0 // add stuff to ret<br>
=C2=A0 =C2=A0 return try;<br>
}</blockquote><div><br></div><div>I like this a lot.=C2=A0</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/CANh8DEm42NZAOzbfSteRnk%2BErYhsSzxyg%=
2BGbtQp3Hm%3DLcZs3WA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANh8DEm42N=
ZAOzbfSteRnk%2BErYhsSzxyg%2BGbtQp3Hm%3DLcZs3WA%40mail.gmail.com</a>.<br />

--001a11439232b85e550541971322--

.

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

Sounds like a nice idea, but can you elaborate a little, maybe with some
more examples? I'm most confused about the "return try" part of this.

--
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/CACGiwhFY8C30LKtApxjopXDJKH-hMrrhaZdL66moW2xf4fUCHw%40mail.gmail.com.

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

<div dir=3D"ltr">Sounds like a nice idea, but can you elaborate a little, m=
aybe with some more examples? I&#39;m most confused about the &quot;return =
try&quot; part of this.<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/CACGiwhFY8C30LKtApxjopXDJKH-hMrrhaZdL=
66moW2xf4fUCHw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CACGiwhFY8C30LKtA=
pxjopXDJKH-hMrrhaZdL66moW2xf4fUCHw%40mail.gmail.com</a>.<br />

--047d7b66fc991db77b054198ac29--

.

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

On 11/18/2016 09:54 PM, D. B. wrote:
> Sounds like a nice idea, but can you elaborate a little, maybe with
> some more examples? I'm most confused about the "return try" part of this.

I'm sorry, I meant "return ret".  "return try" is maybe part of another
proposal :) we have lots of keyword permutations to play with.

To make this a little more formal,

    Within the body and parameter list of a function that does not have
deduced return types:

        decltype(return)

    is the same type as the function's return type.

Example use:

     map<foo, map<set<bar>, baz>>
     with_another_element(const decltype(return)& in, foo new_element) {
         decltype(return) ret;
         ret.insert({new_element, {}});
         return ret;
     }

is equivalent to

     map<foo, map<set<bar>, baz>>
     with_another_element(const map<foo, map<set<bar>, baz>>& in, foo
new_element) {
         map<foo, map<set<bar>, baz>> ret;
         ret.insert({new_element, {}});
         return ret;
     }


> --
> 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
> <mailto:std-proposals+unsubscribe@isocpp.org>.
> To post to this group, send email to std-proposals@isocpp.org
> <mailto:std-proposals@isocpp.org>.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CACGiwhFY8C30LKtApxjopXDJKH-hMrrhaZdL66moW2xf4fUCHw%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CACGiwhFY8C30LKtApxjopXDJKH-hMrrhaZdL66moW2xf4fUCHw%40mail.gmail.com?utm_medium=email&utm_source=footer>.


--
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/213bb5be-1b69-256d-2c11-ec17af169cf6%40scylladb.com.

--------------D85F78FE20D15EEA0E9BDC78
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">
    <div class=3D"moz-cite-prefix">On 11/18/2016 09:54 PM, D. B. wrote:<br>
    </div>
    <blockquote
cite=3D"mid:CACGiwhFY8C30LKtApxjopXDJKH-hMrrhaZdL66moW2xf4fUCHw@mail.gmail.=
com"
      type=3D"cite">
      <div dir=3D"ltr">Sounds like a nice idea, but can you elaborate a
        little, maybe with some more examples? I'm most confused about
        the "return try" part of this.<br>
      </div>
    </blockquote>
    <br>
    I'm sorry, I meant "return ret".=C2=A0 "return try" is maybe part of
    another proposal :) we have lots of keyword permutations to play
    with.<br>
    <br>
    To make this a little more formal,<br>
    <br>
    =C2=A0=C2=A0 Within the body and parameter list of a function that does=
 not
    have deduced return types:<br>
    <br>
    =C2=A0 =C2=A0=C2=A0 =C2=A0 decltype(return)<br>
    <br>
    =C2=A0=C2=A0 is the same type as the function's return type.<br>
    <br>
    Example use:<br>
    <br>
    =C2=A0=C2=A0=C2=A0 map&lt;foo, map&lt;set&lt;bar&gt;, baz&gt;&gt;
    <br>
    =C2=A0=C2=A0=C2=A0 with_another_element(const decltype(return)&amp; in,=
 foo
    new_element) {
    <br>
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 decltype(return) ret;
    <br>
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ret.insert({new_element, {}}=
);<br>
    =C2=A0=C2=A0 =C2=A0 =C2=A0=C2=A0 return ret;
    <br>
    =C2=A0=C2=A0=C2=A0 }<br>
    <br>
    is equivalent to<br>
    <br>
    =C2=A0=C2=A0=C2=A0 map&lt;foo, map&lt;set&lt;bar&gt;, baz&gt;&gt;
    <br>
    =C2=A0=C2=A0=C2=A0 with_another_element(const map&lt;foo, map&lt;set&lt=
;bar&gt;,
    baz&gt;&gt;&amp; in, foo new_element) {
    <br>
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 map&lt;foo, map&lt;set&lt;ba=
r&gt;, baz&gt;&gt; ret;
    <br>
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ret.insert({new_element, {}}=
);<br>
    =C2=A0=C2=A0 =C2=A0 =C2=A0=C2=A0 return ret;
    <br>
    =C2=A0=C2=A0=C2=A0 }<br>
    <br>
    <br>
    <blockquote
cite=3D"mid:CACGiwhFY8C30LKtApxjopXDJKH-hMrrhaZdL66moW2xf4fUCHw@mail.gmail.=
com"
      type=3D"cite">-- <br>
      You received this message because you are subscribed to the Google
      Groups "ISO C++ Standard - Future Proposals" group.<br>
      To unsubscribe from this group and stop receiving emails from it,
      send an email to <a moz-do-not-send=3D"true"
        href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposals+=
unsubscribe@isocpp.org</a>.<br>
      To post to this group, send email to <a moz-do-not-send=3D"true"
        href=3D"mailto:std-proposals@isocpp.org">std-proposals@isocpp.org</=
a>.<br>
      To view this discussion on the web visit <a
        moz-do-not-send=3D"true"
href=3D"https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CACGiw=
hFY8C30LKtApxjopXDJKH-hMrrhaZdL66moW2xf4fUCHw%40mail.gmail.com?utm_medium=
=3Demail&amp;utm_source=3Dfooter">https://groups.google.com/a/isocpp.org/d/=
msgid/std-proposals/CACGiwhFY8C30LKtApxjopXDJKH-hMrrhaZdL66moW2xf4fUCHw%40m=
ail.gmail.com</a>.<br>
    </blockquote>
    <p><br>
    </p>
  </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/213bb5be-1b69-256d-2c11-ec17af169cf6%=
40scylladb.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.googl=
e.com/a/isocpp.org/d/msgid/std-proposals/213bb5be-1b69-256d-2c11-ec17af169c=
f6%40scylladb.com</a>.<br />

--------------D85F78FE20D15EEA0E9BDC78--

.

On 2016-11-18 15:04, Avi Kivity wrote:
> To make this a little more formal,
>
>    Within the body and parameter list of a function that does not have
> deduced return types:

I'm not sure if this restriction is necessary; it might be okay to relax
it to 'as long as the return type has been deduced before
`decltype(return)` is used'.

--
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/582F622B.8000008%40gmail.com.

.

On 11/18/2016 10:18 PM, Matthew Woehlke wrote:
> On 2016-11-18 15:04, Avi Kivity wrote:
>> To make this a little more formal,
>>
>>     Within the body and parameter list of a function that does not have
>> deduced return types:
> I'm not sure if this restriction is necessary; it might be okay to relax
> it to 'as long as the return type has been deduced before
> `decltype(return)` is used'.
>

Yes, that works too, and is useful.


--
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/a927c6c5-5a6c-b8d7-1549-ae72580ca537%40scylladb.com.

.

------=_Part_3606_692588215.1479894646061
Content-Type: multipart/alternative;
 boundary="----=_Part_3607_39679800.1479894646061"

------=_Part_3607_39679800.1479894646061
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



W dniu pi=C4=85tek, 18 listopada 2016 17:01:41 UTC+1 u=C5=BCytkownik Avi Ki=
vity=20
napisa=C5=82:
>
>
> map<foo, map<set<bar>, baz>=20
> complicated(...) {=20
>      decltype(return) ret;=20
>      // add stuff to ret=20
>      return try;=20
> }=20
>
> Instead of repeating the complicated type, refer to it via=20
> decltype(return).  Won't work with deduced return types, of course.=20
>

In your example, you use this hypothetical feature to create up front the=
=20
value you will be returning. I wonder if this is the only use case that=20
drives your feature, because if so, you could consider an alternative=20
feature: give a variable name in the place where you declare the return=20
type:

auto complicated(...) -> map<foo, map<set<bar>, baz> ret // ret is a=20
"return variable"
{=20
  // add stuff to ret=20
} // no return statement is ok: we have an implicit return variable=20

Of course, your solution is more general, it also covers other cases:

map<foo, map<set<bar>, baz>=20
complicated(...)
{=20
  decltype(return) a, b;=20
  // populate a and b
  if (is_better(a, b))
    return a;=20
  else
    return b;
}=20

Regards,
&rzej;

--=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/c54635d6-b882-49a4-9e87-fa0f4bead6ff%40isocpp.or=
g.

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

<div dir=3D"ltr"><br><br>W dniu pi=C4=85tek, 18 listopada 2016 17:01:41 UTC=
+1 u=C5=BCytkownik Avi Kivity napisa=C5=82:<blockquote class=3D"gmail_quote=
" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding=
-left: 1ex;">
<br>map&lt;foo, map&lt;set&lt;bar&gt;, baz&gt;
<br>complicated(...) {
<br>=C2=A0 =C2=A0 =C2=A0decltype(return) ret;
<br>=C2=A0 =C2=A0 =C2=A0// add stuff to ret
<br>=C2=A0 =C2=A0 =C2=A0return try;
<br>}
<br>
<br>Instead of repeating the complicated type, refer to it via=20
<br>decltype(return). =C2=A0Won&#39;t work with deduced return types, of co=
urse.
<br></blockquote><div><br>In your example, you use this hypothetical featur=
e to create up front the value you will be returning. I wonder if this is t=
he only use case that drives your feature, because if so, you could conside=
r an alternative feature: give a variable name in the place where you decla=
re the return type:<br><br><div style=3D"background-color: rgb(250, 250, 25=
0); border-color: rgb(187, 187, 187); border-style: solid; border-width: 1p=
x; overflow-wrap: break-word;" class=3D"prettyprint"><code class=3D"prettyp=
rint"><div class=3D"subprettyprint"><span style=3D"color: #008;" class=3D"s=
tyled-by-prettify">auto</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"> complicated</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">(...)</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>-&gt;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"><code class=
=3D"prettyprint"><span style=3D"color: #000;" class=3D"styled-by-prettify">=
map</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify">foo</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> map</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"color: #=
008;" class=3D"styled-by-prettify">set</span><span style=3D"color: #080;" c=
lass=3D"styled-by-prettify">&lt;bar&gt;</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"> baz</span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">&gt;</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> </span><span style=3D"color: #000;" class=3D"styled-by-prettify"><=
/span></code>ret // ret is a &quot;return variable&quot;<br></span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"><br>=C2=A0 </span><span style=3D"color: #80=
0;" class=3D"styled-by-prettify">// add stuff to ret </span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"></span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">} // no return statement is ok: we have an impli=
cit return variable</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> </span></div></code></div><br>Of course, your solution is more ge=
neral, it also covers other cases:<br><br><div style=3D"background-color: r=
gb(250, 250, 250); border-color: rgb(187, 187, 187); border-style: solid; b=
order-width: 1px; overflow-wrap: break-word;" class=3D"prettyprint"><code c=
lass=3D"prettyprint"><div class=3D"subprettyprint">map&lt;foo, map&lt;set&l=
t;bar&gt;, baz&gt;
<br>complicated(...)<br> {
<br>=C2=A0 decltype(return) a, b;
<br>=C2=A0 // populate a and b<br>=C2=A0 if (is_better(a, b))<br>=C2=A0 =C2=
=A0 return a;
<br>=C2=A0 else<br>=C2=A0=C2=A0=C2=A0 return b;<br>}
<span style=3D"color: #660;" class=3D"styled-by-prettify"></span></div></co=
de></div><br>Regards,<br>&amp;rzej;<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/c54635d6-b882-49a4-9e87-fa0f4bead6ff%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/c54635d6-b882-49a4-9e87-fa0f4bead6ff=
%40isocpp.org</a>.<br />

------=_Part_3607_39679800.1479894646061--

------=_Part_3606_692588215.1479894646061--

.

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

On Wed, Nov 23, 2016 at 9:50 AM, Andrzej Krzemie=C5=84ski <akrzemi1@gmail.c=
om>
wrote:

>
> auto complicated(...) -> map<foo, map<set<bar>, baz> ret // ret is a
> "return variable"
> {
>   // add stuff to ret
> } // no return statement is ok: we have an implicit return variable
>
>
[bikeshed] I don't find this very appealing. It seems prone to errors and
is inapplicable for functions needing early return anyway. [btw, I don't
even like the implicit return 0; in main() very much]

--=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/CACGiwhGVLtZ%2Bq0S_OjLiH%3DLOaDuvEL0QRs_9DAMHo7R=
JVGDSPQ%40mail.gmail.com.

--001a11443f0c3cd1950541f4dd77
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, Nov 23, 2016 at 9:50 AM, Andrzej Krzemie=C5=84ski <span dir=3D"ltr">&lt=
;<a href=3D"mailto:akrzemi1@gmail.com" target=3D"_blank">akrzemi1@gmail.com=
</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin=
:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><=
span class=3D""></span><div><br><div style=3D"background-color:rgb(250,250,=
250);border-color:rgb(187,187,187);border-style:solid;border-width:1px" cla=
ss=3D"m_7333519705254209155prettyprint"><code class=3D"m_733351970525420915=
5prettyprint"><div class=3D"m_7333519705254209155subprettyprint"><span styl=
e=3D"color:#008" class=3D"m_7333519705254209155styled-by-prettify">auto</sp=
an><span style=3D"color:#000" class=3D"m_7333519705254209155styled-by-prett=
ify"> complicated</span><span style=3D"color:#660" class=3D"m_7333519705254=
209155styled-by-prettify">(...)</span><span style=3D"color:#000" class=3D"m=
_7333519705254209155styled-by-prettify"> </span><span style=3D"color:#660" =
class=3D"m_7333519705254209155styled-by-prettify">-&gt;</span><span style=
=3D"color:#000" class=3D"m_7333519705254209155styled-by-prettify"> </span><=
span style=3D"color:#000" class=3D"m_7333519705254209155styled-by-prettify"=
><code class=3D"m_7333519705254209155prettyprint"><span style=3D"color:#000=
" class=3D"m_7333519705254209155styled-by-prettify">map</span><span style=
=3D"color:#660" class=3D"m_7333519705254209155styled-by-prettify">&lt;</spa=
n><span style=3D"color:#000" class=3D"m_7333519705254209155styled-by-pretti=
fy">foo</span><span style=3D"color:#660" class=3D"m_7333519705254209155styl=
ed-by-prettify">,</span><span style=3D"color:#000" class=3D"m_7333519705254=
209155styled-by-prettify"> map</span><span style=3D"color:#660" class=3D"m_=
7333519705254209155styled-by-prettify">&lt;</span><span style=3D"color:#008=
" class=3D"m_7333519705254209155styled-by-prettify">set</span><span style=
=3D"color:#080" class=3D"m_7333519705254209155styled-by-prettify">&lt;bar&g=
t;</span><span style=3D"color:#660" class=3D"m_7333519705254209155styled-by=
-prettify">,</span><span style=3D"color:#000" class=3D"m_733351970525420915=
5styled-by-prettify"> baz</span><span style=3D"color:#660" class=3D"m_73335=
19705254209155styled-by-prettify">&gt;</span><span style=3D"color:#000" cla=
ss=3D"m_7333519705254209155styled-by-prettify"> </span><span style=3D"color=
:#000" class=3D"m_7333519705254209155styled-by-prettify"></span></code>ret =
// ret is a &quot;return variable&quot;<br></span><span style=3D"color:#660=
" class=3D"m_7333519705254209155styled-by-prettify">{</span><span style=3D"=
color:#000" class=3D"m_7333519705254209155styled-by-prettify"> </span><span=
 style=3D"color:#000" class=3D"m_7333519705254209155styled-by-prettify"><br=
>=C2=A0 </span><span style=3D"color:#800" class=3D"m_7333519705254209155sty=
led-by-prettify">// add stuff to ret </span><span style=3D"color:#000" clas=
s=3D"m_7333519705254209155styled-by-prettify"></span><span style=3D"color:#=
000" class=3D"m_7333519705254209155styled-by-prettify"><br></span><span sty=
le=3D"color:#660" class=3D"m_7333519705254209155styled-by-prettify">} // no=
 return statement is ok: we have an implicit return variable</span><span st=
yle=3D"color:#000" class=3D"m_7333519705254209155styled-by-prettify"> </spa=
n></div></code></div><br></div></div></blockquote></div><br></div><div clas=
s=3D"gmail_extra">[bikeshed] I don&#39;t find this very appealing. It seems=
 prone to errors and is inapplicable for functions needing early return any=
way. [btw, I don&#39;t even like the implicit return 0; in main() very much=
]<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/CACGiwhGVLtZ%2Bq0S_OjLiH%3DLOaDuvEL0Q=
Rs_9DAMHo7RJVGDSPQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CACGiwhGVLtZ%=
2Bq0S_OjLiH%3DLOaDuvEL0QRs_9DAMHo7RJVGDSPQ%40mail.gmail.com</a>.<br />

--001a11443f0c3cd1950541f4dd77--

.

------=_Part_9072_923188554.1479902205436
Content-Type: multipart/alternative;
 boundary="----=_Part_9073_305032425.1479902205436"

------=_Part_9073_305032425.1479902205436
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



W dniu =C5=9Broda, 23 listopada 2016 10:53:45 UTC+1 u=C5=BCytkownik D. B. n=
apisa=C5=82:
>
> On Wed, Nov 23, 2016 at 9:50 AM, Andrzej Krzemie=C5=84ski <akrz...@gmail.=
com=20
> <javascript:>> wrote:
>
>>
>> auto complicated(...) -> map<foo, map<set<bar>, baz> ret // ret is a=20
>> "return variable"
>> {=20
>>   // add stuff to ret=20
>> } // no return statement is ok: we have an implicit return variable=20
>>
>>
> [bikeshed] I don't find this very appealing. It seems prone to errors and=
=20
> is inapplicable for functions needing early return anyway. [btw, I don't=
=20
> even like the implicit return 0; in main() very much]
>

Just two comments, now that you have explored this.=20

   1. Having an implicit return value does not prevent you from explicitly=
=20
   returning something else. =20
   2. This solution is less implicit than the case of main, because you=20
   have to explicitly say that you are using an implicit return value.

But you may be right, that this might turn out to be prone to errors.=20
Without playing with it, one never knows.


Regards,

&rzej;

--=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/48215717-5938-4bc3-a033-2a4e71fbd4b6%40isocpp.or=
g.

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

<div dir=3D"ltr"><br><br>W dniu =C5=9Broda, 23 listopada 2016 10:53:45 UTC+=
1 u=C5=BCytkownik D. B. napisa=C5=82:<blockquote class=3D"gmail_quote" styl=
e=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left:=
 1ex;"><div dir=3D"ltr"><div><div class=3D"gmail_quote">On Wed, Nov 23, 201=
6 at 9:50 AM, Andrzej Krzemie=C5=84ski <span dir=3D"ltr">&lt;<a href=3D"jav=
ascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"U_vh8hhKAwAJ" rel=3D"n=
ofollow" onmousedown=3D"this.href=3D&#39;javascript:&#39;;return true;" onc=
lick=3D"this.href=3D&#39;javascript:&#39;;return true;">akrz...@gmail.com</=
a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0=
 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><sp=
an></span><div><br><div style=3D"background-color:rgb(250,250,250);border-c=
olor:rgb(187,187,187);border-style:solid;border-width:1px"><code><div><span=
 style=3D"color:#008">auto</span><span style=3D"color:#000"> complicated</s=
pan><span style=3D"color:#660">(...)</span><span style=3D"color:#000"> </sp=
an><span style=3D"color:#660">-&gt;</span><span style=3D"color:#000"> </spa=
n><span style=3D"color:#000"><code><span style=3D"color:#000">map</span><sp=
an style=3D"color:#660">&lt;</span><span style=3D"color:#000">foo</span><sp=
an style=3D"color:#660">,</span><span style=3D"color:#000"> map</span><span=
 style=3D"color:#660">&lt;</span><span style=3D"color:#008">set</span><span=
 style=3D"color:#080">&lt;bar&gt;</span><span style=3D"color:#660">,</span>=
<span style=3D"color:#000"> baz</span><span style=3D"color:#660">&gt;</span=
><span style=3D"color:#000"> </span><span style=3D"color:#000"></span></cod=
e>ret // ret is a &quot;return variable&quot;<br></span><span style=3D"colo=
r:#660">{</span><span style=3D"color:#000"> </span><span style=3D"color:#00=
0"><br>=C2=A0 </span><span style=3D"color:#800">// add stuff to ret </span>=
<span style=3D"color:#000"></span><span style=3D"color:#000"><br></span><sp=
an style=3D"color:#660">} // no return statement is ok: we have an implicit=
 return variable</span><span style=3D"color:#000"> </span></div></code></di=
v><br></div></div></blockquote></div><br></div><div>[bikeshed] I don&#39;t =
find this very appealing. It seems prone to errors and is inapplicable for =
functions needing early return anyway. [btw, I don&#39;t even like the impl=
icit return 0; in main() very much]<br></div></div></blockquote><div><br>Ju=
st two comments, now that you have explored this. <br><ol><li>Having an imp=
licit return value does not prevent you from explicitly returning something=
 else.=C2=A0 </li><li>This solution is less implicit than the case of main,=
 because you have to explicitly say that you are using an implicit return v=
alue.</li></ol><p>But you may be right, that this might turn out to be pron=
e to errors. Without playing with it, one never knows.</p><p><br></p><p>Reg=
ards,</p><p>&amp;rzej;<br></p></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/48215717-5938-4bc3-a033-2a4e71fbd4b6%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/48215717-5938-4bc3-a033-2a4e71fbd4b6=
%40isocpp.org</a>.<br />

------=_Part_9073_305032425.1479902205436--

------=_Part_9072_923188554.1479902205436--

.

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

On Wed, Nov 23, 2016 at 11:56 AM, Andrzej Krzemie=C5=84ski <akrzemi1@gmail.=
com>
wrote:

>
> Just two comments, now that you have explored this.
>
>    1. Having an implicit return value does not prevent you from
>    explicitly returning something else.
>    2. This solution is less implicit than the case of main, because you
>    have to explicitly say that you are using an implicit return value.
>
> But you may be right, that this might turn out to be prone to errors.
> Without playing with it, one never knows.
>
>
> Regards,
>
> &rzej;
>

Indeed, maybe it's not so bad and could be useful. While I can't think of
many uses for it personally, it would actually be interesting to see it
explored further, like some use cases where it could help a lot.

This idea reminded me of Visual Basic, where a function would return the
value that was most recently assigned to its own name... but having a
separate name or a specific keyword is probably better or even required in
C++, as this would avoid (somewhat contrived) ambiguities with e.g.
function pointers, recursion, etc.

Did you envision that the return variable could be called anything, or is
"ret" intended to be a sort of keyword here?

--=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/CACGiwhHzduoNfWE46BA3TrWqwCr2JtexbjWS7sdmGD0ZfH%=
3Dcmg%40mail.gmail.com.

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
On Wed, Nov 23, 2016 at 11:56 AM, Andrzej Krzemie=C5=84ski <span dir=3D"ltr=
">&lt;<a href=3D"mailto:akrzemi1@gmail.com" target=3D"_blank">akrzemi1@gmai=
l.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"m=
argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"l=
tr"><br><div>Just two comments, now that you have explored this. <br><ol><l=
i>Having an implicit return value does not prevent you from explicitly retu=
rning something else.=C2=A0 </li><li>This solution is less implicit than th=
e case of main, because you have to explicitly say that you are using an im=
plicit return value.</li></ol><p>But you may be right, that this might turn=
 out to be prone to errors. Without playing with it, one never knows.</p><p=
><br></p><p>Regards,</p><p>&amp;rzej;</p></div></div></blockquote><div>=C2=
=A0</div></div>Indeed, maybe it&#39;s not so bad and could be useful. While=
 I can&#39;t think of many uses for it personally, it would actually be int=
eresting to see it explored further, like some use cases where it could hel=
p a lot.<br><br>This idea reminded me of Visual Basic, where a function wou=
ld return the value that was most recently assigned to its own name... but =
having a separate name or a specific keyword is probably better or even req=
uired in C++, as this would avoid (somewhat contrived) ambiguities with e.g=
.. function pointers, recursion, etc.<br><br></div><div class=3D"gmail_extra=
">Did you envision that the return variable could be called anything, or is=
 &quot;ret&quot; intended to be a sort of keyword here?<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/CACGiwhHzduoNfWE46BA3TrWqwCr2JtexbjWS=
7sdmGD0ZfH%3Dcmg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CACGiwhHzduoNfW=
E46BA3TrWqwCr2JtexbjWS7sdmGD0ZfH%3Dcmg%40mail.gmail.com</a>.<br />

--001a1130cf066b23270541f6dc40--

.

------=_Part_1400_92063097.1479904344110
Content-Type: multipart/alternative;
 boundary="----=_Part_1401_1121808690.1479904344111"

------=_Part_1401_1121808690.1479904344111
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



W dniu =C5=9Broda, 23 listopada 2016 13:16:41 UTC+1 u=C5=BCytkownik D. B. n=
apisa=C5=82:
>
>
> On Wed, Nov 23, 2016 at 11:56 AM, Andrzej Krzemie=C5=84ski <akrz...@gmail=
..com=20
> <javascript:>> wrote:
>
>>
>> Just two comments, now that you have explored this.=20
>>
>>    1. Having an implicit return value does not prevent you from=20
>>    explicitly returning something else. =20
>>    2. This solution is less implicit than the case of main, because you=
=20
>>    have to explicitly say that you are using an implicit return value.
>>
>> But you may be right, that this might turn out to be prone to errors.=20
>> Without playing with it, one never knows.
>>
>>
>> Regards,
>>
>> &rzej;
>>
> =20
> Indeed, maybe it's not so bad and could be useful. While I can't think of=
=20
> many uses for it personally, it would actually be interesting to see it=
=20
> explored further, like some use cases where it could help a lot.
>
> This idea reminded me of Visual Basic, where a function would return the=
=20
> value that was most recently assigned to its own name... but having a=20
> separate name or a specific keyword is probably better or even required i=
n=20
> C++, as this would avoid (somewhat contrived) ambiguities with e.g.=20
> function pointers, recursion, etc.
>
> Did you envision that the return variable could be called anything, or is=
=20
> "ret" intended to be a sort of keyword here?
>

No keyword. You pick the name for it, as for any other variable. This has=
=20
been already implemented in Go: https://tour.golang.org/basics/7

Regards,
&rzej;

--=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/98786c89-5e30-4985-b4b1-a972b568f691%40isocpp.or=
g.

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

<div dir=3D"ltr"><br><br>W dniu =C5=9Broda, 23 listopada 2016 13:16:41 UTC+=
1 u=C5=BCytkownik D. B. napisa=C5=82:<blockquote class=3D"gmail_quote" styl=
e=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left:=
 1ex;"><div dir=3D"ltr"><div><br><div class=3D"gmail_quote">On Wed, Nov 23,=
 2016 at 11:56 AM, Andrzej Krzemie=C5=84ski <span dir=3D"ltr">&lt;<a href=
=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"fMMKuOVRAwAJ" r=
el=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&#39;;return tru=
e;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true;">akrz...@gmai=
l.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"m=
argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"l=
tr"><br><div>Just two comments, now that you have explored this. <br><ol><l=
i>Having an implicit return value does not prevent you from explicitly retu=
rning something else.=C2=A0 </li><li>This solution is less implicit than th=
e case of main, because you have to explicitly say that you are using an im=
plicit return value.</li></ol><p>But you may be right, that this might turn=
 out to be prone to errors. Without playing with it, one never knows.</p><p=
><br></p><p>Regards,</p><p>&amp;rzej;</p></div></div></blockquote><div>=C2=
=A0</div></div>Indeed, maybe it&#39;s not so bad and could be useful. While=
 I can&#39;t think of many uses for it personally, it would actually be int=
eresting to see it explored further, like some use cases where it could hel=
p a lot.<br><br>This idea reminded me of Visual Basic, where a function wou=
ld return the value that was most recently assigned to its own name... but =
having a separate name or a specific keyword is probably better or even req=
uired in C++, as this would avoid (somewhat contrived) ambiguities with e.g=
.. function pointers, recursion, etc.<br><br></div><div>Did you envision tha=
t the return variable could be called anything, or is &quot;ret&quot; inten=
ded to be a sort of keyword here?<br></div></div></blockquote><div><br>No k=
eyword. You pick the name for it, as for any other variable. This has been =
already implemented in Go: <a href=3D"https://tour.golang.org/basics/7">htt=
ps://tour.golang.org/basics/7</a><br><br>Regards,<br>&amp;rzej;<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/98786c89-5e30-4985-b4b1-a972b568f691%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/98786c89-5e30-4985-b4b1-a972b568f691=
%40isocpp.org</a>.<br />

------=_Part_1401_1121808690.1479904344111--

------=_Part_1400_92063097.1479904344110--

.

------=_Part_2833_116060510.1479916023559
Content-Type: multipart/alternative;
 boundary="----=_Part_2834_166171781.1479916023559"

------=_Part_2834_166171781.1479916023559
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



On Wednesday, November 23, 2016 at 6:56:45 AM UTC-5, Andrzej Krzemie=C5=84s=
ki=20
wrote:
>
>
>
> W dniu =C5=9Broda, 23 listopada 2016 10:53:45 UTC+1 u=C5=BCytkownik D. B.=
 napisa=C5=82:
>>
>> On Wed, Nov 23, 2016 at 9:50 AM, Andrzej Krzemie=C5=84ski <akrz...@gmail=
..com>=20
>> wrote:
>>
>>>
>>> auto complicated(...) -> map<foo, map<set<bar>, baz> ret // ret is a=20
>>> "return variable"
>>> {=20
>>>   // add stuff to ret=20
>>> } // no return statement is ok: we have an implicit return variable=20
>>>
>>>
>> [bikeshed] I don't find this very appealing. It seems prone to errors an=
d=20
>> is inapplicable for functions needing early return anyway. [btw, I don't=
=20
>> even like the implicit return 0; in main() very much]
>>
>
> Just two comments, now that you have explored this.=20
>
>    1. Having an implicit return value does not prevent you from=20
>    explicitly returning something else. =20
>
> This is getting a bit off-topic (since there are plenty of uses for=20
`decltype(return)` besides declaring a variable to be returned), but...

C++'s function model gives every function a return value object. As it=20
currently stands, this object is initialized by the `return` statement, but=
=20
the storage for it always exists (provided by the caller).

If you can *name* this variable, then it seems to me that what you're doing=
=20
is giving the user *direct access* to the return value object itself. This=
=20
named return value object is being initialized at the start of the=20
function, and the user gets to manipulate it in whatever way they see fit.=
=20
If you are directly manipulating the return value object, it *must* be=20
impossible for a user to return "something else".

Oh sure, a return statement in a function with a named return value (NRV)=
=20
could simply perform the equivalent of assigning the returned expression to=
=20
the NRV. Or even destroying the existing NRV object and re-creating it=20
in-situ (which is perfectly legal C++). But you aren't truly returning=20
"something else"; you're just doing what a typical `return` statement would=
=20
do.

There are two things I don't like about directly accessing the return value=
=20
object the way you define it is this.

1: Where it gets named.

You name it in the function's signature. Why? Users of the function don't=
=20
need to know the name. Users of the function don't even need to know that=
=20
it *has a name*. I suppose you could treat the name as optional, the way=20
parameter names are optional. But I don't think function signatures need=20
more optional things.

2: Where it gets initialized.

With your way, it must be initialized at the start of the function, before=
=20
the first `{`. A `return` statement may overwrite it, but since it has a=20
name, it must be an initialized variable. This means that you would have to=
=20
invoke a lambda to do more complex initialization of the return variable.=
=20
Even worse, catching exceptions would be a big pain.

What you really want is syntax to initialize the return value and get a=20
non-const reference to it. This syntax can be invoked at any point in the=
=20
function's execution. You should be able to do this more than once, with=20
each time destroying the existing object if any and creating a new one.

Invoking `return expr` or `return {...}` statement would also re-initialize=
=20
the return value, if it was already initialized. However, an empty=20
`return;` statement will not re-initialize the return value object; it=20
would simply returning the existing return value. If no object had been=20
created, then UB results. Compilers can detect the trivial cases of you=20
screwing this up and issue a warning, but obviously they can't detect them=
=20
all.

This could combine well with P0057-style continuations, which plays games=
=20
with the return value.

But in any case, the primary motivation for this kind of functionality is=
=20
giving us guaranteed named return value elision.

--=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/c2420b29-2644-481c-a9be-c6a642e80e0f%40isocpp.or=
g.

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

<div dir=3D"ltr"><br><br>On Wednesday, November 23, 2016 at 6:56:45 AM UTC-=
5, Andrzej Krzemie=C5=84ski 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"><br><br>W dniu =C5=9Broda, 23 listopada 2016 10:53:4=
5 UTC+1 u=C5=BCytkownik D. B. napisa=C5=82:<blockquote class=3D"gmail_quote=
" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-le=
ft:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_quote">On Wed, Nov 23, 20=
16 at 9:50 AM, Andrzej Krzemie=C5=84ski <span dir=3D"ltr">&lt;<a rel=3D"nof=
ollow">akrz...@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmai=
l_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left=
:1ex"><div dir=3D"ltr"><span></span><div><br><div style=3D"background-color=
:rgb(250,250,250);border-color:rgb(187,187,187);border-style:solid;border-w=
idth:1px"><code><div><span style=3D"color:#008">auto</span><span style=3D"c=
olor:#000"> complicated</span><span style=3D"color:#660">(...)</span><span =
style=3D"color:#000"> </span><span style=3D"color:#660">-&gt;</span><span s=
tyle=3D"color:#000"> </span><span style=3D"color:#000"><code><span style=3D=
"color:#000">map</span><span style=3D"color:#660">&lt;</span><span style=3D=
"color:#000">foo</span><span style=3D"color:#660">,</span><span style=3D"co=
lor:#000"> map</span><span style=3D"color:#660">&lt;</span><span style=3D"c=
olor:#008">set</span><span style=3D"color:#080">&lt;bar&gt;</span><span sty=
le=3D"color:#660">,</span><span style=3D"color:#000"> baz</span><span style=
=3D"color:#660">&gt;</span><span style=3D"color:#000"> </span><span style=
=3D"color:#000"></span></code>ret // ret is a &quot;return variable&quot;<b=
r></span><span style=3D"color:#660">{</span><span style=3D"color:#000"> </s=
pan><span style=3D"color:#000"><br>=C2=A0 </span><span style=3D"color:#800"=
>// add stuff to ret </span><span style=3D"color:#000"></span><span style=
=3D"color:#000"><br></span><span style=3D"color:#660">} // no return statem=
ent is ok: we have an implicit return variable</span><span style=3D"color:#=
000"> </span></div></code></div><br></div></div></blockquote></div><br></di=
v><div>[bikeshed] I don&#39;t find this very appealing. It seems prone to e=
rrors and is inapplicable for functions needing early return anyway. [btw, =
I don&#39;t even like the implicit return 0; in main() very much]<br></div>=
</div></blockquote><div><br>Just two comments, now that you have explored t=
his. <br><ol><li>Having an implicit return value does not prevent you from =
explicitly returning something else.=C2=A0 </li></ol></div></div></blockquo=
te><div>This is getting a bit off-topic (since there are plenty of uses for=
 `decltype(return)` besides declaring a variable to be returned), but...<br=
><br>C++&#39;s function model gives every function a return value object. A=
s it currently stands, this object is initialized by the `return` statement=
, but the storage for it always exists (provided by the caller).<br><br>If =
you can <i>name</i> this variable, then it seems to me that what you&#39;re=
 doing is giving the user <i>direct access</i> to the return value object i=
tself. This named return value object is being initialized at the start of =
the function, and the user gets to manipulate it in whatever way they see f=
it. If you are directly manipulating the return value object, it <i>must</i=
> be impossible for a user to return &quot;something else&quot;.<br><br>Oh =
sure, a return statement in a function with a named return value (NRV) coul=
d simply perform the equivalent of assigning the returned expression to the=
 NRV. Or even destroying the existing NRV object and re-creating it in-situ=
 (which is perfectly legal C++). But you aren&#39;t truly returning &quot;s=
omething else&quot;; you&#39;re just doing what a typical `return` statemen=
t would do.</div><br>There are two things I don&#39;t like about directly a=
ccessing the return value object the way you define it is this.<br><br>1: W=
here it gets named.<br><br>You name it in the function&#39;s signature. Why=
? Users of the function don&#39;t need to know the name. Users of the funct=
ion don&#39;t even need to know that it <i>has a name</i>. I suppose you co=
uld treat the name as optional, the way parameter names are optional. But I=
 don&#39;t think function signatures need more optional things.<br><br>2: W=
here it gets initialized.<br><br>With your way, it must be initialized at t=
he start of the function, before the first `{`. A `return` statement may ov=
erwrite it, but since it has a name, it must be an initialized variable. Th=
is means that you would have to invoke a lambda to do more complex initiali=
zation of the return variable. Even worse, catching exceptions would be a b=
ig pain.<br><br>What you really want is syntax to initialize the return val=
ue and get a non-const reference to it. This syntax can be invoked at any p=
oint in the function&#39;s execution. You should be able to do this more th=
an once, with each time destroying the existing object if any and creating =
a new one.<br><br>Invoking `return expr` or `return {...}` statement would =
also re-initialize the return value, if it was already initialized. However=
, an empty `return;` statement will not re-initialize the return value obje=
ct; it would simply returning the existing return value. If no object had b=
een created, then UB results. Compilers can detect the trivial cases of you=
 screwing this up and issue a warning, but obviously they can&#39;t detect =
them all.<br><br>This could combine well with P0057-style continuations, wh=
ich plays games with the return value.<br><br>But in any case, the primary =
motivation for this kind of functionality is giving us guaranteed named ret=
urn value elision.<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/c2420b29-2644-481c-a9be-c6a642e80e0f%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/c2420b29-2644-481c-a9be-c6a642e80e0f=
%40isocpp.org</a>.<br />

------=_Part_2834_166171781.1479916023559--

------=_Part_2833_116060510.1479916023559--

.

On 11/18/2016 06:01 PM, Avi Kivity wrote:
>
> map<foo, map<set<bar>, baz>
> complicated(...) {
>     decltype(return) ret;
>     // add stuff to ret
>     return try;
> }
>
> Instead of repeating the complicated type, refer to it via
> decltype(return).  Won't work with deduced return types, of course.
>

It seems like this was favorably received.  How do I make progress with
this?  Is there a proposal genie I can bribe to turn it into a paper?
Or at least a proposal template I can fill in?

I'm afraid I won't be able to present it in person, but I'm willing to
work on wording (to my limited ability in the matter) if someone will
pick it up and present it.

--
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/f471b0d3-0517-45b5-9477-9281447df1fd%40scylladb.com.

.

------=_Part_6281_463330247.1479939521374
Content-Type: multipart/alternative;
 boundary="----=_Part_6282_1076532717.1479939521374"

------=_Part_6282_1076532717.1479939521374
Content-Type: text/plain; charset=UTF-8

Generally you'd need to write a paper for EWG.  It is one that we would
then look at, though unless there is someone at the meeting 'pushing' for
it, it likely wouldn't get considered.  Also, it becomes less likely in the
next meeting or two solely due C++17 nearly finalized, but it is something
that could hang around for C++2x

I think I'll be spending some time in Evolution, but if I get a bit of
time, perhaps I can write something up.

On Wednesday, November 23, 2016 at 8:36:56 AM UTC-8, Avi Kivity wrote:
>
> On 11/18/2016 06:01 PM, Avi Kivity wrote:
> >
> > map<foo, map<set<bar>, baz>
> > complicated(...) {
> >     decltype(return) ret;
> >     // add stuff to ret
> >     return try;
> > }
> >
> > Instead of repeating the complicated type, refer to it via
> > decltype(return).  Won't work with deduced return types, of course.
> >
>
> It seems like this was favorably received.  How do I make progress with
> this?  Is there a proposal genie I can bribe to turn it into a paper?
> Or at least a proposal template I can fill in?
>
> I'm afraid I won't be able to present it in person, but I'm willing to
> work on wording (to my limited ability in the matter) if someone will
> pick it up and present it.
>

--
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/70a6baa9-315d-493c-a1d6-c65f4b781c66%40isocpp.org.

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

<div dir=3D"ltr">Generally you&#39;d need to write a paper for EWG.=C2=A0 I=
t is one that we would then look at, though unless there is someone at the =
meeting &#39;pushing&#39; for it, it likely wouldn&#39;t get considered.=C2=
=A0 Also, it becomes less likely in the next meeting or two solely due C++1=
7 nearly finalized, but it is something that could hang around for C++2x<br=
><br>I think I&#39;ll be spending some time in Evolution, but if I get a bi=
t of time, perhaps I can write something up.<br><br>On Wednesday, November =
23, 2016 at 8:36:56 AM UTC-8, Avi Kivity wrote:<blockquote class=3D"gmail_q=
uote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;pad=
ding-left: 1ex;">On 11/18/2016 06:01 PM, Avi Kivity wrote:
<br>&gt;
<br>&gt; map&lt;foo, map&lt;set&lt;bar&gt;, baz&gt;
<br>&gt; complicated(...) {
<br>&gt; =C2=A0 =C2=A0 decltype(return) ret;
<br>&gt; =C2=A0 =C2=A0 // add stuff to ret
<br>&gt; =C2=A0 =C2=A0 return try;
<br>&gt; }
<br>&gt;
<br>&gt; Instead of repeating the complicated type, refer to it via=20
<br>&gt; decltype(return). =C2=A0Won&#39;t work with deduced return types, =
of course.
<br>&gt;
<br>
<br>It seems like this was favorably received. =C2=A0How do I make progress=
 with=20
<br>this? =C2=A0Is there a proposal genie I can bribe to turn it into a pap=
er? =C2=A0
<br>Or at least a proposal template I can fill in?
<br>
<br>I&#39;m afraid I won&#39;t be able to present it in person, but I&#39;m=
 willing to=20
<br>work on wording (to my limited ability in the matter) if someone will=
=20
<br>pick it up and present it.
<br></blockquote></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/70a6baa9-315d-493c-a1d6-c65f4b781c66%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/70a6baa9-315d-493c-a1d6-c65f4b781c66=
%40isocpp.org</a>.<br />

------=_Part_6282_1076532717.1479939521374--

------=_Part_6281_463330247.1479939521374--

.

On Fri, Nov 18, 2016 at 06:01:37PM +0200, Avi Kivity wrote:
>
> map<foo, map<set<bar>, baz>
> complicated(...) {
>     decltype(return) ret;
>     // add stuff to ret
>     return try;
> }
>
> Instead of repeating the complicated type, refer to it via decltype(return).
> Won't work with deduced return types, of course.

I will pick up on the bikeshed here.

In GCC before 3.4 there was an "named return value extension" that looks
pretty similar to the one proposed here, they used the syntax

map<foo, map<set<bar>, baz>
complicated(...)
  return ret
{
  // add stuff to ret
  return ret;
}

Should this example of earlier implementation be allowed to influence the
design?

See also https://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_5.html#SEC106

/MF

--
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/20161124000202.GA7985%40noemi.

.

------=_Part_10871_886314380.1479951489455
Content-Type: multipart/alternative;
 boundary="----=_Part_10872_1178844353.1479951489455"

------=_Part_10872_1178844353.1479951489455
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



On Wednesday, November 23, 2016 at 1:50:46 AM UTC-8, Andrzej Krzemie=C5=84s=
ki=20
wrote:
>
>
>
> W dniu pi=C4=85tek, 18 listopada 2016 17:01:41 UTC+1 u=C5=BCytkownik Avi =
Kivity=20
> napisa=C5=82:
>>
>>
>> map<foo, map<set<bar>, baz>=20
>> complicated(...) {=20
>>      decltype(return) ret;=20
>>      // add stuff to ret=20
>>      return try;=20
>> }=20
>>
>> Instead of repeating the complicated type, refer to it via=20
>> decltype(return).  Won't work with deduced return types, of course.=20
>>
>
> In your example, you use this hypothetical feature to create up front the=
=20
> value you will be returning. I wonder if this is the only use case that=
=20
> drives your feature, because if so, you could consider an alternative=20
> feature: give a variable name in the place where you declare the return=
=20
> type:
>
> auto complicated(...) -> map<foo, map<set<bar>, baz> ret // ret is a=20
> "return variable"
> {=20
>   // add stuff to ret=20
> } // no return statement is ok: we have an implicit return variable=20
>
> Of course, your solution is more general, it also covers other cases:
>
> map<foo, map<set<bar>, baz>=20
> complicated(...)
> {=20
>   decltype(return) a, b;=20
>   // populate a and b
>   if (is_better(a, b))
>     return a;=20
>   else
>     return b;
> }=20
>
> Regards,
> &rzej;
>

The syntax you propose could be extremely expensive, since it would require=
=20
default constructing the variable, and then mutating it.  Of course, if the=
=20
mutation isn't permissible (such as in an immutable type), this would fail.=
=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/c06dd3eb-0018-43e7-8437-2fc152774c5b%40isocpp.or=
g.

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

<div dir=3D"ltr"><br><br>On Wednesday, November 23, 2016 at 1:50:46 AM UTC-=
8, Andrzej Krzemie=C5=84ski 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"><br><br>W dniu pi=C4=85tek, 18 listopada 2016 17:01:=
41 UTC+1 u=C5=BCytkownik Avi Kivity napisa=C5=82:<blockquote class=3D"gmail=
_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">
<br>map&lt;foo, map&lt;set&lt;bar&gt;, baz&gt;
<br>complicated(...) {
<br>=C2=A0 =C2=A0 =C2=A0decltype(return) ret;
<br>=C2=A0 =C2=A0 =C2=A0// add stuff to ret
<br>=C2=A0 =C2=A0 =C2=A0return try;
<br>}
<br>
<br>Instead of repeating the complicated type, refer to it via=20
<br>decltype(return). =C2=A0Won&#39;t work with deduced return types, of co=
urse.
<br></blockquote><div><br>In your example, you use this hypothetical featur=
e to create up front the value you will be returning. I wonder if this is t=
he only use case that drives your feature, because if so, you could conside=
r an alternative feature: give a variable name in the place where you decla=
re the return type:<br><br><div style=3D"background-color:rgb(250,250,250);=
border-color:rgb(187,187,187);border-style:solid;border-width:1px"><code><d=
iv><span style=3D"color:#008">auto</span><span style=3D"color:#000"> compli=
cated</span><span style=3D"color:#660">(...)</span><span style=3D"color:#00=
0"> </span><span style=3D"color:#660">-&gt;</span><span style=3D"color:#000=
"> </span><span style=3D"color:#000"><code><span style=3D"color:#000">map</=
span><span style=3D"color:#660">&lt;</span><span style=3D"color:#000">foo</=
span><span style=3D"color:#660">,</span><span style=3D"color:#000"> map</sp=
an><span style=3D"color:#660">&lt;</span><span style=3D"color:#008">set</sp=
an><span style=3D"color:#080">&lt;bar&gt;</span><span style=3D"color:#660">=
,</span><span style=3D"color:#000"> baz</span><span style=3D"color:#660">&g=
t;</span><span style=3D"color:#000"> </span><span style=3D"color:#000"></sp=
an></code>ret // ret is a &quot;return variable&quot;<br></span><span style=
=3D"color:#660">{</span><span style=3D"color:#000"> </span><span style=3D"c=
olor:#000"><br>=C2=A0 </span><span style=3D"color:#800">// add stuff to ret=
 </span><span style=3D"color:#000"></span><span style=3D"color:#000"><br></=
span><span style=3D"color:#660">} // no return statement is ok: we have an =
implicit return variable</span><span style=3D"color:#000"> </span></div></c=
ode></div><br>Of course, your solution is more general, it also covers othe=
r cases:<br><br><div style=3D"background-color:rgb(250,250,250);border-colo=
r:rgb(187,187,187);border-style:solid;border-width:1px"><code><div>map&lt;f=
oo, map&lt;set&lt;bar&gt;, baz&gt;
<br>complicated(...)<br> {
<br>=C2=A0 decltype(return) a, b;
<br>=C2=A0 // populate a and b<br>=C2=A0 if (is_better(a, b))<br>=C2=A0 =C2=
=A0 return a;
<br>=C2=A0 else<br>=C2=A0=C2=A0=C2=A0 return b;<br>}
<span style=3D"color:#660"></span></div></code></div><br>Regards,<br>&amp;r=
zej;<br></div></div></blockquote><div><br>The syntax you propose could be e=
xtremely expensive, since it would require default constructing the variabl=
e, and then mutating it.=C2=A0 Of course, if the mutation isn&#39;t permiss=
ible (such as in an immutable type), this would fail. <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/c06dd3eb-0018-43e7-8437-2fc152774c5b%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/c06dd3eb-0018-43e7-8437-2fc152774c5b=
%40isocpp.org</a>.<br />

------=_Part_10872_1178844353.1479951489455--

------=_Part_10871_886314380.1479951489455--

.

------=_Part_7905_1353492217.1479976162805
Content-Type: multipart/alternative;
 boundary="----=_Part_7906_1998233133.1479976162805"

------=_Part_7906_1998233133.1479976162805
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



W dniu =C5=9Broda, 23 listopada 2016 16:47:03 UTC+1 u=C5=BCytkownik Nicol B=
olas=20
napisa=C5=82:
>
>
>
> On Wednesday, November 23, 2016 at 6:56:45 AM UTC-5, Andrzej Krzemie=C5=
=84ski=20
> wrote:
>>
>>
>>
>> W dniu =C5=9Broda, 23 listopada 2016 10:53:45 UTC+1 u=C5=BCytkownik D. B=
.. napisa=C5=82:
>>>
>>> On Wed, Nov 23, 2016 at 9:50 AM, Andrzej Krzemie=C5=84ski <akrz...@gmai=
l.com>=20
>>> wrote:
>>>
>>>>
>>>> auto complicated(...) -> map<foo, map<set<bar>, baz> ret // ret is a=
=20
>>>> "return variable"
>>>> {=20
>>>>   // add stuff to ret=20
>>>> } // no return statement is ok: we have an implicit return variable=20
>>>>
>>>>
>>> [bikeshed] I don't find this very appealing. It seems prone to errors=
=20
>>> and is inapplicable for functions needing early return anyway. [btw, I=
=20
>>> don't even like the implicit return 0; in main() very much]
>>>
>>
>> Just two comments, now that you have explored this.=20
>>
>>    1. Having an implicit return value does not prevent you from=20
>>    explicitly returning something else. =20
>>
>> This is getting a bit off-topic (since there are plenty of uses for=20
> `decltype(return)` besides declaring a variable to be returned), but...
>
> C++'s function model gives every function a return value object. As it=20
> currently stands, this object is initialized by the `return` statement, b=
ut=20
> the storage for it always exists (provided by the caller).
>
> If you can *name* this variable, then it seems to me that what you're=20
> doing is giving the user *direct access* to the return value object=20
> itself. This named return value object is being initialized at the start =
of=20
> the function, and the user gets to manipulate it in whatever way they see=
=20
> fit. If you are directly manipulating the return value object, it *must*=
=20
> be impossible for a user to return "something else".
>
> Oh sure, a return statement in a function with a named return value (NRV)=
=20
> could simply perform the equivalent of assigning the returned expression =
to=20
> the NRV. Or even destroying the existing NRV object and re-creating it=20
> in-situ (which is perfectly legal C++). But you aren't truly returning=20
> "something else"; you're just doing what a typical `return` statement wou=
ld=20
> do.
>
> There are two things I don't like about directly accessing the return=20
> value object the way you define it is this.
>
> 1: Where it gets named.
>
> You name it in the function's signature. Why? Users of the function don't=
=20
> need to know the name. Users of the function don't even need to know that=
=20
> it *has a name*. I suppose you could treat the name as optional, the way=
=20
> parameter names are optional. But I don't think function signatures need=
=20
> more optional things.
>

Just to clarify a couple of points on this "vision". Such implicit return=
=20
variable is not part of function signature. Function separated into a=20
declaration and a definition would look like this:

// declaration:
map<foo, map<set<bar>, baz> complicated(...);

// definition:
auto complicated(...) -> map<foo, map<set<bar>, baz> ret {baz{}} // return=
=20
value is initialized
{=20
  // add stuff to ret=20
}

This is similar to taking an int by value in a declaration and by const=20
value in the definition:

void fun(int x);      // declaration
void fun(const int x) // definition
{}

Also, as shown in the example above there is a way to initialize te return=
=20
variable with an arbitrary initialization.

Regards,
&rzej;


=20
=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/28bbe0cb-48a1-471d-9850-d6c34310f69a%40isocpp.or=
g.

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

<div dir=3D"ltr"><br><br>W dniu =C5=9Broda, 23 listopada 2016 16:47:03 UTC+=
1 u=C5=BCytkownik Nicol Bolas napisa=C5=82:<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"><br><br>On Wednesday, November 23, 2016 at 6:=
56:45 AM UTC-5, Andrzej Krzemie=C5=84ski wrote:<blockquote class=3D"gmail_q=
uote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;paddin=
g-left:1ex"><div dir=3D"ltr"><br><br>W dniu =C5=9Broda, 23 listopada 2016 1=
0:53:45 UTC+1 u=C5=BCytkownik D. B. napisa=C5=82:<blockquote class=3D"gmail=
_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_quote">On Wed, Nov =
23, 2016 at 9:50 AM, Andrzej Krzemie=C5=84ski <span dir=3D"ltr">&lt;<a rel=
=3D"nofollow">akrz...@gmail.com</a>&gt;</span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"ltr"><span></span><div><br><div style=3D"backgrou=
nd-color:rgb(250,250,250);border-color:rgb(187,187,187);border-style:solid;=
border-width:1px"><code><div><span style=3D"color:#008">auto</span><span st=
yle=3D"color:#000"> complicated</span><span style=3D"color:#660">(...)</spa=
n><span style=3D"color:#000"> </span><span style=3D"color:#660">-&gt;</span=
><span style=3D"color:#000"> </span><span style=3D"color:#000"><code><span =
style=3D"color:#000">map</span><span style=3D"color:#660">&lt;</span><span =
style=3D"color:#000">foo</span><span style=3D"color:#660">,</span><span sty=
le=3D"color:#000"> map</span><span style=3D"color:#660">&lt;</span><span st=
yle=3D"color:#008">set</span><span style=3D"color:#080">&lt;bar&gt;</span><=
span style=3D"color:#660">,</span><span style=3D"color:#000"> baz</span><sp=
an style=3D"color:#660">&gt;</span><span style=3D"color:#000"> </span><span=
 style=3D"color:#000"></span></code>ret // ret is a &quot;return variable&q=
uot;<br></span><span style=3D"color:#660">{</span><span style=3D"color:#000=
"> </span><span style=3D"color:#000"><br>=C2=A0 </span><span style=3D"color=
:#800">// add stuff to ret </span><span style=3D"color:#000"></span><span s=
tyle=3D"color:#000"><br></span><span style=3D"color:#660">} // no return st=
atement is ok: we have an implicit return variable</span><span style=3D"col=
or:#000"> </span></div></code></div><br></div></div></blockquote></div><br>=
</div><div>[bikeshed] I don&#39;t find this very appealing. It seems prone =
to errors and is inapplicable for functions needing early return anyway. [b=
tw, I don&#39;t even like the implicit return 0; in main() very much]<br></=
div></div></blockquote><div><br>Just two comments, now that you have explor=
ed this. <br><ol><li>Having an implicit return value does not prevent you f=
rom explicitly returning something else.=C2=A0 </li></ol></div></div></bloc=
kquote><div>This is getting a bit off-topic (since there are plenty of uses=
 for `decltype(return)` besides declaring a variable to be returned), but..=
..<br><br>C++&#39;s function model gives every function a return value objec=
t. As it currently stands, this object is initialized by the `return` state=
ment, but the storage for it always exists (provided by the caller).<br><br=
>If you can <i>name</i> this variable, then it seems to me that what you&#3=
9;re doing is giving the user <i>direct access</i> to the return value obje=
ct itself. This named return value object is being initialized at the start=
 of the function, and the user gets to manipulate it in whatever way they s=
ee fit. If you are directly manipulating the return value object, it <i>mus=
t</i> be impossible for a user to return &quot;something else&quot;.<br><br=
>Oh sure, a return statement in a function with a named return value (NRV) =
could simply perform the equivalent of assigning the returned expression to=
 the NRV. Or even destroying the existing NRV object and re-creating it in-=
situ (which is perfectly legal C++). But you aren&#39;t truly returning &qu=
ot;something else&quot;; you&#39;re just doing what a typical `return` stat=
ement would do.</div><br>There are two things I don&#39;t like about direct=
ly accessing the return value object the way you define it is this.<br><br>=
1: Where it gets named.<br><br>You name it in the function&#39;s signature.=
 Why? Users of the function don&#39;t need to know the name. Users of the f=
unction don&#39;t even need to know that it <i>has a name</i>. I suppose yo=
u could treat the name as optional, the way parameter names are optional. B=
ut I don&#39;t think function signatures need more optional things.<br></di=
v></blockquote><div><br>Just to clarify a couple of points on this &quot;vi=
sion&quot;. Such implicit return variable is not part of function signature=
.. Function separated into a declaration and a definition would look like th=
is:<br><br><code><div style=3D"background-color: rgb(250, 250, 250); border=
-color: rgb(187, 187, 187); border-style: solid; border-width: 1px; overflo=
w-wrap: break-word;" class=3D"prettyprint"><code class=3D"prettyprint"><div=
 class=3D"subprettyprint">// declaration:<br><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"><code><code class=3D"prettyprint"><span style=
=3D"color: #000;" class=3D"styled-by-prettify">map</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify">foo</span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> map</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">&lt;</span><span style=3D"color: #008;" class=3D"styled-by-pret=
tify">set</span><span style=3D"color: #080;" class=3D"styled-by-prettify">&=
lt;bar&gt;</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> baz</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">&gt; </span></c=
ode></code></span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
><code><code class=3D"prettyprint"><span style=3D"color: #660;" class=3D"st=
yled-by-prettify"><code><code class=3D"prettyprint"><span style=3D"color: #=
000;" class=3D"styled-by-prettify">complicated</span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">(...);<br><br>// definition:</span></co=
de></code></span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
</span></code></code></span><span style=3D"color: #008;" class=3D"styled-by=
-prettify"><br>auto</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> complicated</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">(...)</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">-&g=
t;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> map</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify">foo</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"> map</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">&lt;</span><span style=3D"color: #008;" cl=
ass=3D"styled-by-prettify">set</span><span style=3D"color: #080;" class=3D"=
styled-by-prettify">&lt;bar&gt;</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> baz</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">&gt;</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
 ret </span><span style=3D"color: #660;" class=3D"styled-by-prettify">{</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify">baz</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">{}}</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #800;" class=3D"styled-by-prettify">// return value is initialized</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> <br>=C2=A0 </span><span style=
=3D"color: #800;" class=3D"styled-by-prettify">// add stuff to ret </span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">}</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"><br></span></div></code></div><sp=
an style=3D"color:#660"><br></span></code>This is similar to taking an int =
by value in a declaration and by const value in the definition:<br><br><div=
 style=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 187,=
 187); border-style: solid; border-width: 1px; overflow-wrap: break-word;" =
class=3D"prettyprint"><code class=3D"prettyprint"><div class=3D"subprettypr=
int"><span style=3D"color: #008;" class=3D"styled-by-prettify">void</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"> fun</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"c=
olor: #008;" class=3D"styled-by-prettify">int</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> x</span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">);</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </span><span style=3D"col=
or: #800;" class=3D"styled-by-prettify">// declaration</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color=
: #008;" class=3D"styled-by-prettify">void</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"> fun</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">(</span><span style=3D"color: #008;" class=3D"sty=
led-by-prettify">const</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettif=
y">int</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> x</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">)</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #800;" class=3D"styled-by-prettify">// definition</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">{}</span></div></code></div><br=
>Also, as shown in the example above there is a way to initialize te return=
 variable with an arbitrary initialization.<br><br>Regards,<br>&amp;rzej;<b=
r><br><br>=C2=A0<br></div><div>=C2=A0</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/28bbe0cb-48a1-471d-9850-d6c34310f69a%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/28bbe0cb-48a1-471d-9850-d6c34310f69a=
%40isocpp.org</a>.<br />

------=_Part_7906_1998233133.1479976162805--

------=_Part_7905_1353492217.1479976162805--

.

------=_Part_388_1757470816.1479976324462
Content-Type: multipart/alternative;
 boundary="----=_Part_389_539178220.1479976324463"

------=_Part_389_539178220.1479976324463
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



W dniu czwartek, 24 listopada 2016 02:38:09 UTC+1 u=C5=BCytkownik Erich Kea=
ne=20
napisa=C5=82:
>
>
>
> On Wednesday, November 23, 2016 at 1:50:46 AM UTC-8, Andrzej Krzemie=C5=
=84ski=20
> wrote:
>>
>>
>>
>> W dniu pi=C4=85tek, 18 listopada 2016 17:01:41 UTC+1 u=C5=BCytkownik Avi=
 Kivity=20
>> napisa=C5=82:
>>>
>>>
>>> map<foo, map<set<bar>, baz>=20
>>> complicated(...) {=20
>>>      decltype(return) ret;=20
>>>      // add stuff to ret=20
>>>      return try;=20
>>> }=20
>>>
>>> Instead of repeating the complicated type, refer to it via=20
>>> decltype(return).  Won't work with deduced return types, of course.=20
>>>
>>
>> In your example, you use this hypothetical feature to create up front th=
e=20
>> value you will be returning. I wonder if this is the only use case that=
=20
>> drives your feature, because if so, you could consider an alternative=20
>> feature: give a variable name in the place where you declare the return=
=20
>> type:
>>
>> auto complicated(...) -> map<foo, map<set<bar>, baz> ret // ret is a=20
>> "return variable"
>> {=20
>>   // add stuff to ret=20
>> } // no return statement is ok: we have an implicit return variable=20
>>
>> Of course, your solution is more general, it also covers other cases:
>>
>> map<foo, map<set<bar>, baz>=20
>> complicated(...)
>> {=20
>>   decltype(return) a, b;=20
>>   // populate a and b
>>   if (is_better(a, b))
>>     return a;=20
>>   else
>>     return b;
>> }=20
>>
>> Regards,
>> &rzej;
>>
>
> The syntax you propose could be extremely expensive, since it would=20
> require default constructing the variable, and then mutating it.  Of=20
> course, if the mutation isn't permissible (such as in an immutable type),=
=20
> this would fail.=20
>

Not necessarily. I have explained it in another reply. But this is your=20
thread with your proposal. My main goal with this is to encourage you to=20
come up with a detailed motivation, range of use cases you want to cover,=
=20
comparison with other solutions, and rationale on why you chose your=20
solution over others, like mine here.

Regards,
&rzej;

--=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/44a7b501-f124-49c7-8c89-05be39139d2f%40isocpp.or=
g.

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

<div dir=3D"ltr"><br><br>W dniu czwartek, 24 listopada 2016 02:38:09 UTC+1 =
u=C5=BCytkownik Erich Keane napisa=C5=82:<blockquote class=3D"gmail_quote" =
style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-l=
eft: 1ex;"><div dir=3D"ltr"><br><br>On Wednesday, November 23, 2016 at 1:50=
:46 AM UTC-8, Andrzej Krzemie=C5=84ski 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"><br><br>W dniu pi=C4=85tek, 18 listopada 2016 17=
:01:41 UTC+1 u=C5=BCytkownik Avi Kivity napisa=C5=82:<blockquote class=3D"g=
mail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;=
padding-left:1ex">
<br>map&lt;foo, map&lt;set&lt;bar&gt;, baz&gt;
<br>complicated(...) {
<br>=C2=A0 =C2=A0 =C2=A0decltype(return) ret;
<br>=C2=A0 =C2=A0 =C2=A0// add stuff to ret
<br>=C2=A0 =C2=A0 =C2=A0return try;
<br>}
<br>
<br>Instead of repeating the complicated type, refer to it via=20
<br>decltype(return). =C2=A0Won&#39;t work with deduced return types, of co=
urse.
<br></blockquote><div><br>In your example, you use this hypothetical featur=
e to create up front the value you will be returning. I wonder if this is t=
he only use case that drives your feature, because if so, you could conside=
r an alternative feature: give a variable name in the place where you decla=
re the return type:<br><br><div style=3D"background-color:rgb(250,250,250);=
border-color:rgb(187,187,187);border-style:solid;border-width:1px"><code><d=
iv><span style=3D"color:#008">auto</span><span style=3D"color:#000"> compli=
cated</span><span style=3D"color:#660">(...)</span><span style=3D"color:#00=
0"> </span><span style=3D"color:#660">-&gt;</span><span style=3D"color:#000=
"> </span><span style=3D"color:#000"><code><span style=3D"color:#000">map</=
span><span style=3D"color:#660">&lt;</span><span style=3D"color:#000">foo</=
span><span style=3D"color:#660">,</span><span style=3D"color:#000"> map</sp=
an><span style=3D"color:#660">&lt;</span><span style=3D"color:#008">set</sp=
an><span style=3D"color:#080">&lt;bar&gt;</span><span style=3D"color:#660">=
,</span><span style=3D"color:#000"> baz</span><span style=3D"color:#660">&g=
t;</span><span style=3D"color:#000"> </span><span style=3D"color:#000"></sp=
an></code>ret // ret is a &quot;return variable&quot;<br></span><span style=
=3D"color:#660">{</span><span style=3D"color:#000"> </span><span style=3D"c=
olor:#000"><br>=C2=A0 </span><span style=3D"color:#800">// add stuff to ret=
 </span><span style=3D"color:#000"></span><span style=3D"color:#000"><br></=
span><span style=3D"color:#660">} // no return statement is ok: we have an =
implicit return variable</span><span style=3D"color:#000"> </span></div></c=
ode></div><br>Of course, your solution is more general, it also covers othe=
r cases:<br><br><div style=3D"background-color:rgb(250,250,250);border-colo=
r:rgb(187,187,187);border-style:solid;border-width:1px"><code><div>map&lt;f=
oo, map&lt;set&lt;bar&gt;, baz&gt;
<br>complicated(...)<br> {
<br>=C2=A0 decltype(return) a, b;
<br>=C2=A0 // populate a and b<br>=C2=A0 if (is_better(a, b))<br>=C2=A0 =C2=
=A0 return a;
<br>=C2=A0 else<br>=C2=A0=C2=A0=C2=A0 return b;<br>}
<span style=3D"color:#660"></span></div></code></div><br>Regards,<br>&amp;r=
zej;<br></div></div></blockquote><div><br>The syntax you propose could be e=
xtremely expensive, since it would require default constructing the variabl=
e, and then mutating it.=C2=A0 Of course, if the mutation isn&#39;t permiss=
ible (such as in an immutable type), this would fail. <br></div></div></blo=
ckquote><div><br>Not necessarily. I have explained it in another reply. But=
 this is your thread with your proposal. My main goal with this is to encou=
rage you to come up with a detailed motivation, range of use cases you want=
 to cover, comparison with other solutions, and rationale on why you chose =
your solution over others, like mine here.<br><br>Regards,<br>&amp;rzej;<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/44a7b501-f124-49c7-8c89-05be39139d2f%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/44a7b501-f124-49c7-8c89-05be39139d2f=
%40isocpp.org</a>.<br />

------=_Part_389_539178220.1479976324463--

------=_Part_388_1757470816.1479976324462--

.

--089e01229296608263054212d343
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Thu, Nov 24, 2016 at 3:32 AM, Andrzej Krzemie=C5=84ski <akrzemi1@gmail.c=
om>
wrote:

>
>
> W dniu czwartek, 24 listopada 2016 02:38:09 UTC+1 u=C5=BCytkownik Erich K=
eane
> napisa=C5=82:
>>
>>
>>
>> On Wednesday, November 23, 2016 at 1:50:46 AM UTC-8, Andrzej Krzemie=C5=
=84ski
>> wrote:
>>>
>>>
>>>
>>> W dniu pi=C4=85tek, 18 listopada 2016 17:01:41 UTC+1 u=C5=BCytkownik Av=
i Kivity
>>> napisa=C5=82:
>>>>
>>>>
>>>> map<foo, map<set<bar>, baz>
>>>> complicated(...) {
>>>>      decltype(return) ret;
>>>>      // add stuff to ret
>>>>      return try;
>>>> }
>>>>
>>>> Instead of repeating the complicated type, refer to it via
>>>> decltype(return).  Won't work with deduced return types, of course.
>>>>
>>>
>>> In your example, you use this hypothetical feature to create up front
>>> the value you will be returning. I wonder if this is the only use case =
that
>>> drives your feature, because if so, you could consider an alternative
>>> feature: give a variable name in the place where you declare the return
>>> type:
>>>
>>> auto complicated(...) -> map<foo, map<set<bar>, baz> ret // ret is a
>>> "return variable"
>>> {
>>>   // add stuff to ret
>>> } // no return statement is ok: we have an implicit return variable
>>>
>>> Of course, your solution is more general, it also covers other cases:
>>>
>>> map<foo, map<set<bar>, baz>
>>> complicated(...)
>>> {
>>>   decltype(return) a, b;
>>>   // populate a and b
>>>   if (is_better(a, b))
>>>     return a;
>>>   else
>>>     return b;
>>> }
>>>
>>> Regards,
>>> &rzej;
>>>
>>
>> The syntax you propose could be extremely expensive, since it would
>> require default constructing the variable, and then mutating it.  Of
>> course, if the mutation isn't permissible (such as in an immutable type)=
,
>> this would fail.
>>
>
> Not necessarily. I have explained it in another reply. But this is your
> thread with your proposal. My main goal with this is to encourage you to
> come up with a detailed motivation, range of use cases you want to cover,
> comparison with other solutions, and rationale on why you chose your
> solution over others, like mine here.
>
> Regards,
> &rzej;
>
>

IMO, decltype(return) just looks better.
It is more similar to what we already have.
It doesn't clutter the function signature (which is getting cluttered with
throw/noexcept, concepts/requires, contracts, ...)

--=20
Be seeing you,
Tony

--=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/CAOHCbiuinycU0%2Bej3gMG0EoytK8mONyjuUqZWTB2cA7xb=
SnNNg%40mail.gmail.com.

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

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Thu, Nov 24, 2016 at 3:32 AM, Andrzej Krzemie=C5=84ski <span dir=3D"=
ltr">&lt;<a href=3D"mailto:akrzemi1@gmail.com" target=3D"_blank">akrzemi1@g=
mail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=
=3D"ltr"><div><div class=3D"h5"><br><br>W dniu czwartek, 24 listopada 2016 =
02:38:09 UTC+1 u=C5=BCytkownik Erich Keane napisa=C5=82:<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"><br><br>On Wednesday, November 23, =
2016 at 1:50:46 AM UTC-8, Andrzej Krzemie=C5=84ski 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"><br><br>W dniu pi=C4=85tek, 18 list=
opada 2016 17:01:41 UTC+1 u=C5=BCytkownik Avi Kivity napisa=C5=82:<blockquo=
te class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
<br>map&lt;foo, map&lt;set&lt;bar&gt;, baz&gt;
<br>complicated(...) {
<br>=C2=A0 =C2=A0 =C2=A0decltype(return) ret;
<br>=C2=A0 =C2=A0 =C2=A0// add stuff to ret
<br>=C2=A0 =C2=A0 =C2=A0return try;
<br>}
<br>
<br>Instead of repeating the complicated type, refer to it via=20
<br>decltype(return).=C2=A0 Won&#39;t work with deduced return types, of co=
urse.
<br></blockquote><div><br>In your example, you use this hypothetical featur=
e to create up front the value you will be returning. I wonder if this is t=
he only use case that drives your feature, because if so, you could conside=
r an alternative feature: give a variable name in the place where you decla=
re the return type:<br><br><div style=3D"background-color:rgb(250,250,250);=
border-color:rgb(187,187,187);border-style:solid;border-width:1px"><code><d=
iv><span style=3D"color:#008">auto</span><span style=3D"color:#000"> compli=
cated</span><span style=3D"color:#660">(...)</span><span style=3D"color:#00=
0"> </span><span style=3D"color:#660">-&gt;</span><span style=3D"color:#000=
"> </span><span style=3D"color:#000"><code><span style=3D"color:#000">map</=
span><span style=3D"color:#660">&lt;</span><span style=3D"color:#000">foo</=
span><span style=3D"color:#660">,</span><span style=3D"color:#000"> map</sp=
an><span style=3D"color:#660">&lt;</span><span style=3D"color:#008">set</sp=
an><span style=3D"color:#080">&lt;bar&gt;</span><span style=3D"color:#660">=
,</span><span style=3D"color:#000"> baz</span><span style=3D"color:#660">&g=
t;</span><span style=3D"color:#000"> </span><span style=3D"color:#000"></sp=
an></code>ret // ret is a &quot;return variable&quot;<br></span><span style=
=3D"color:#660">{</span><span style=3D"color:#000"> </span><span style=3D"c=
olor:#000"><br>=C2=A0 </span><span style=3D"color:#800">// add stuff to ret=
 </span><span style=3D"color:#000"></span><span style=3D"color:#000"><br></=
span><span style=3D"color:#660">} // no return statement is ok: we have an =
implicit return variable</span><span style=3D"color:#000"> </span></div></c=
ode></div><br>Of course, your solution is more general, it also covers othe=
r cases:<br><br><div style=3D"background-color:rgb(250,250,250);border-colo=
r:rgb(187,187,187);border-style:solid;border-width:1px"><code><div>map&lt;f=
oo, map&lt;set&lt;bar&gt;, baz&gt;
<br>complicated(...)<br> {
<br>=C2=A0 decltype(return) a, b;
<br>=C2=A0 // populate a and b<br>=C2=A0 if (is_better(a, b))<br>=C2=A0 =C2=
=A0 return a;
<br>=C2=A0 else<br>=C2=A0=C2=A0=C2=A0 return b;<br>}
<span style=3D"color:#660"></span></div></code></div><br>Regards,<br>&amp;r=
zej;<br></div></div></blockquote><div><br>The syntax you propose could be e=
xtremely expensive, since it would require default constructing the variabl=
e, and then mutating it.=C2=A0 Of course, if the mutation isn&#39;t permiss=
ible (such as in an immutable type), this would fail. <br></div></div></blo=
ckquote></div></div><div><br>Not necessarily. I have explained it in anothe=
r reply. But this is your thread with your proposal. My main goal with this=
 is to encourage you to come up with a detailed motivation, range of use ca=
ses you want to cover, comparison with other solutions, and rationale on wh=
y you chose your solution over others, like mine here.<br><br>Regards,<br>&=
amp;rzej;<br></div></div><span class=3D"">

<p></p>

</span></blockquote><div><br><br></div></div>IMO, decltype(return) just loo=
ks better.<br></div><div class=3D"gmail_extra">It is more similar to what w=
e already have.<br></div><div class=3D"gmail_extra">It doesn&#39;t clutter =
the function signature (which is getting cluttered with throw/noexcept, con=
cepts/requires, contracts, ...)<br clear=3D"all"></div><div class=3D"gmail_=
extra"><br>-- <br><div class=3D"gmail_signature" data-smartmail=3D"gmail_si=
gnature"><div dir=3D"ltr"><div>Be seeing you,<br></div>Tony<br></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/CAOHCbiuinycU0%2Bej3gMG0EoytK8mONyjuU=
qZWTB2cA7xbSnNNg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOHCbiuinycU0%=
2Bej3gMG0EoytK8mONyjuUqZWTB2cA7xbSnNNg%40mail.gmail.com</a>.<br />

--089e01229296608263054212d343--

.

------=_Part_8086_1923413685.1480026374631
Content-Type: multipart/alternative;
 boundary="----=_Part_8087_1327853358.1480026374631"

------=_Part_8087_1327853358.1480026374631
Content-Type: text/plain; charset=UTF-8

On Friday, November 18, 2016 at 5:01:41 PM UTC+1, Avi Kivity wrote:
>
>
> map<foo, map<set<bar>, baz>
> complicated(...) {
>      decltype(return) ret;
>      // add stuff to ret
>      return try;
> }
>
> Instead of repeating the complicated type, refer to it via
> decltype(return).  Won't work with deduced return types, of course.
>

This has been suggested informally several times already, but afaik nobody
did the work to write a paper and present it.
For instance:
https://groups.google.com/a/isocpp.org/d/topic/std-proposals/wdX31-nWSnc/discussion
(it also appears in the discussions about allowing explicit constructors in
return statements)

--
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/108e091f-526e-47b9-b8c9-3c77452a965d%40isocpp.org.

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

<div dir=3D"ltr">On Friday, November 18, 2016 at 5:01:41 PM UTC+1, Avi Kivi=
ty wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: =
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<br>map&lt;foo, map&lt;set&lt;bar&gt;, baz&gt;
<br>complicated(...) {
<br>=C2=A0 =C2=A0 =C2=A0decltype(return) ret;
<br>=C2=A0 =C2=A0 =C2=A0// add stuff to ret
<br>=C2=A0 =C2=A0 =C2=A0return try;
<br>}
<br>
<br>Instead of repeating the complicated type, refer to it via=20
<br>decltype(return). =C2=A0Won&#39;t work with deduced return types, of co=
urse.<br></blockquote><div><br>This has been suggested informally several t=
imes already, but afaik nobody did the work to write a paper and present it=
..<br>For instance:<br>https://groups.google.com/a/isocpp.org/d/topic/std-pr=
oposals/wdX31-nWSnc/discussion<br>(it also appears in the discussions about=
 allowing explicit constructors in return statements)<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/108e091f-526e-47b9-b8c9-3c77452a965d%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/108e091f-526e-47b9-b8c9-3c77452a965d=
%40isocpp.org</a>.<br />

------=_Part_8087_1327853358.1480026374631--

------=_Part_8086_1923413685.1480026374631--

.

On 11/24/2016 10:38 PM, Tony V E wrote:

> IMO, decltype(return) just looks better.
> It is more similar to what we already have.
> It doesn't clutter the function signature (which is getting cluttered
> with throw/noexcept, concepts/requires, contracts, ...)

And it can be used in more places, like

   auto c = std::max<decltype(return)>(a, b);

--
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/6792a178-e63d-fa8c-882d-c85f1657c850%40mail1.stofanet.dk.

.

------=_Part_5589_740598688.1480028167149
Content-Type: multipart/alternative;
 boundary="----=_Part_5590_1311858694.1480028167149"

------=_Part_5590_1311858694.1480028167149
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



W dniu =C5=9Broda, 23 listopada 2016 17:36:56 UTC+1 u=C5=BCytkownik Avi Kiv=
ity=20
napisa=C5=82:
>
> On 11/18/2016 06:01 PM, Avi Kivity wrote:=20
> >=20
> > map<foo, map<set<bar>, baz>=20
> > complicated(...) {=20
> >     decltype(return) ret;=20
> >     // add stuff to ret=20
> >     return try;=20
> > }=20
> >=20
> > Instead of repeating the complicated type, refer to it via=20
> > decltype(return).  Won't work with deduced return types, of course.=20
> >=20
>
> It seems like this was favorably received.  How do I make progress with=
=20
> this?  Is there a proposal genie I can bribe to turn it into a paper?  =
=20
> Or at least a proposal template I can fill in?=20
>
> I'm afraid I won't be able to present it in person, but I'm willing to=20
> work on wording (to my limited ability in the matter) if someone will=20
> pick it up and present it.=20
>

My experience shows that it is never one proposal, but a number of=20
iterations: you write a proposal, you receive feedback, you write a=20
revision, you receive a second feedback, and so on, until the proposal is=
=20
mature enough. For the initial version wording may not be necessary, but it=
=20
would be worth to consider more nasty cases. For instance:

struct X { void * p; }; // sizeof(X) =3D=3D 8

std::vector<X> fun()
{
    struct X {}; // sizeof(X) =3D=3D 1=20
    decltype(return) v;
    return v;
}

The question is, should decltype(return) be exactly the same type we have=
=20
seen in function return type, or should it be a token-by token copy paste=
=20
of the function's return type. Or in other owrds, should it work like this:

typedef std::vector<X> THE_TYPE;
THE_TYPE fun()
{
    THE_TYPE v;
}

or like this:

#define THE_TYPE std::vector<X>
THE_TYPE fun()
{
    THE_TYPE v;
}

We probably want the former, but it would be worth mentioning it=20
explicitly, in case some implementation tries to do a token pastin.

Regards,
&rzej; =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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/cf82daf4-436e-421e-b644-83ba298e3a9e%40isocpp.or=
g.

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

<div dir=3D"ltr"><br><br>W dniu =C5=9Broda, 23 listopada 2016 17:36:56 UTC+=
1 u=C5=BCytkownik Avi Kivity napisa=C5=82:<blockquote class=3D"gmail_quote"=
 style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: =
rgb(204, 204, 204); border-left-width: 1px; border-left-style: solid;">On 1=
1/18/2016 06:01 PM, Avi Kivity wrote:
<br>&gt;
<br>&gt; map&lt;foo, map&lt;set&lt;bar&gt;, baz&gt;
<br>&gt; complicated(...) {
<br>&gt; =C2=A0 =C2=A0 decltype(return) ret;
<br>&gt; =C2=A0 =C2=A0 // add stuff to ret
<br>&gt; =C2=A0 =C2=A0 return try;
<br>&gt; }
<br>&gt;
<br>&gt; Instead of repeating the complicated type, refer to it via=20
<br>&gt; decltype(return). =C2=A0Won&#39;t work with deduced return types, =
of course.
<br>&gt;
<br>
<br>It seems like this was favorably received. =C2=A0How do I make progress=
 with=20
<br>this? =C2=A0Is there a proposal genie I can bribe to turn it into a pap=
er? =C2=A0
<br>Or at least a proposal template I can fill in?
<br>
<br>I&#39;m afraid I won&#39;t be able to present it in person, but I&#39;m=
 willing to=20
<br>work on wording (to my limited ability in the matter) if someone will=
=20
<br>pick it up and present it.
<br></blockquote><div><br></div><div>My experience shows that it is never o=
ne=20
proposal, but a number of iterations: you write a proposal, you receive=20
feedback, you write a revision, you receive a second feedback, and so=20
on, until the proposal is mature enough. For the initial version wording
 may not be necessary, but it would be worth to consider more nasty=20
cases. For instance:<br><br><div class=3D"prettyprint" style=3D"border: 1px=
 solid rgb(187, 187, 187); border-image: none; background-color: rgb(250, 2=
50, 250); overflow-wrap: break-word;"><code class=3D"prettyprint"><div clas=
s=3D"subprettyprint"><span class=3D"styled-by-prettify" style=3D"color: rgb=
(0, 0, 136);">struct</span><span class=3D"styled-by-prettify" style=3D"colo=
r: rgb(0, 0, 0);"> X </span><span class=3D"styled-by-prettify" style=3D"col=
or: rgb(102, 102, 0);">{</span><span class=3D"styled-by-prettify" style=3D"=
color: rgb(0, 0, 0);"> </span><span class=3D"styled-by-prettify" style=3D"c=
olor: rgb(0, 0, 136);">void</span><span class=3D"styled-by-prettify" style=
=3D"color: rgb(0, 0, 0);"> </span><span class=3D"styled-by-prettify" style=
=3D"color: rgb(102, 102, 0);">*</span><span class=3D"styled-by-prettify" st=
yle=3D"color: rgb(0, 0, 0);"> p</span><span class=3D"styled-by-prettify" st=
yle=3D"color: rgb(102, 102, 0);">;</span><span class=3D"styled-by-prettify"=
 style=3D"color: rgb(0, 0, 0);"> </span><span class=3D"styled-by-prettify" =
style=3D"color: rgb(102, 102, 0);">};</span><span class=3D"styled-by-pretti=
fy" style=3D"color: rgb(0, 0, 0);"> </span><span class=3D"styled-by-prettif=
y" style=3D"color: rgb(136, 0, 0);">// sizeof(X) =3D=3D 8</span><span class=
=3D"styled-by-prettify" style=3D"color: rgb(0, 0, 0);"><br><br>std</span><s=
pan class=3D"styled-by-prettify" style=3D"color: rgb(102, 102, 0);">::</spa=
n><span class=3D"styled-by-prettify" style=3D"color: rgb(0, 0, 0);">vector<=
/span><span class=3D"styled-by-prettify" style=3D"color: rgb(102, 102, 0);"=
>&lt;</span><span class=3D"styled-by-prettify" style=3D"color: rgb(0, 0, 0)=
;">X</span><span class=3D"styled-by-prettify" style=3D"color: rgb(102, 102,=
 0);">&gt;</span><span class=3D"styled-by-prettify" style=3D"color: rgb(0, =
0, 0);"> fun</span><span class=3D"styled-by-prettify" style=3D"color: rgb(1=
02, 102, 0);">()</span><span class=3D"styled-by-prettify" style=3D"color: r=
gb(0, 0, 0);"><br></span><span class=3D"styled-by-prettify" style=3D"color:=
 rgb(102, 102, 0);">{</span><span class=3D"styled-by-prettify" style=3D"col=
or: rgb(0, 0, 0);"><br>=C2=A0 =C2=A0 </span><span class=3D"styled-by-pretti=
fy" style=3D"color: rgb(0, 0, 136);">struct</span><span class=3D"styled-by-=
prettify" style=3D"color: rgb(0, 0, 0);"> X </span><span class=3D"styled-by=
-prettify" style=3D"color: rgb(102, 102, 0);">{};</span><span class=3D"styl=
ed-by-prettify" style=3D"color: rgb(0, 0, 0);"> </span><span class=3D"style=
d-by-prettify" style=3D"color: rgb(136, 0, 0);">// sizeof(X) =3D=3D 1 </spa=
n><span class=3D"styled-by-prettify" style=3D"color: rgb(0, 0, 0);"><br>=C2=
=A0 =C2=A0 </span><span class=3D"styled-by-prettify" style=3D"color: rgb(0,=
 0, 136);">decltype</span><span class=3D"styled-by-prettify" style=3D"color=
: rgb(102, 102, 0);">(</span><span class=3D"styled-by-prettify" style=3D"co=
lor: rgb(0, 0, 136);">return</span><span class=3D"styled-by-prettify" style=
=3D"color: rgb(102, 102, 0);">)</span><span class=3D"styled-by-prettify" st=
yle=3D"color: rgb(0, 0, 0);"> v</span><span class=3D"styled-by-prettify" st=
yle=3D"color: rgb(102, 102, 0);">;</span><span class=3D"styled-by-prettify"=
 style=3D"color: rgb(0, 0, 0);"><br>=C2=A0 =C2=A0 </span><span class=3D"sty=
led-by-prettify" style=3D"color: rgb(0, 0, 136);">return</span><span class=
=3D"styled-by-prettify" style=3D"color: rgb(0, 0, 0);"> v</span><span class=
=3D"styled-by-prettify" style=3D"color: rgb(102, 102, 0);">;</span><span cl=
ass=3D"styled-by-prettify" style=3D"color: rgb(0, 0, 0);"><br></span><span =
class=3D"styled-by-prettify" style=3D"color: rgb(102, 102, 0);">}</span></d=
iv></code></div><br>The
 question is, should decltype(return) be exactly the same type we have=20
seen in function return type, or should it be a token-by token copy=20
paste of the function&#39;s return type. Or in other owrds, should it work=
=20
like this:<br><br><div class=3D"prettyprint" style=3D"border: 1px solid rgb=
(187, 187, 187); border-image: none; background-color: rgb(250, 250, 250); =
overflow-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"subpr=
ettyprint"><span class=3D"styled-by-prettify" style=3D"color: rgb(0, 0, 136=
);">typedef</span><span class=3D"styled-by-prettify" style=3D"color: rgb(0,=
 0, 0);"> std</span><span class=3D"styled-by-prettify" style=3D"color: rgb(=
102, 102, 0);">::</span><span class=3D"styled-by-prettify" style=3D"color: =
rgb(0, 0, 0);">vector</span><span class=3D"styled-by-prettify" style=3D"col=
or: rgb(102, 102, 0);">&lt;</span><span class=3D"styled-by-prettify" style=
=3D"color: rgb(0, 0, 0);">X</span><span class=3D"styled-by-prettify" style=
=3D"color: rgb(102, 102, 0);">&gt;</span><span class=3D"styled-by-prettify"=
 style=3D"color: rgb(0, 0, 0);"> THE_TYPE</span><span class=3D"styled-by-pr=
ettify" style=3D"color: rgb(102, 102, 0);">;</span><span class=3D"styled-by=
-prettify" style=3D"color: rgb(0, 0, 0);"><br>THE_TYPE fun</span><span clas=
s=3D"styled-by-prettify" style=3D"color: rgb(102, 102, 0);">()</span><span =
class=3D"styled-by-prettify" style=3D"color: rgb(0, 0, 0);"><br></span><spa=
n class=3D"styled-by-prettify" style=3D"color: rgb(102, 102, 0);">{</span><=
span class=3D"styled-by-prettify" style=3D"color: rgb(0, 0, 0);"><br>=C2=A0=
 =C2=A0 THE_TYPE v</span><span class=3D"styled-by-prettify" style=3D"color:=
 rgb(102, 102, 0);">;</span><span class=3D"styled-by-prettify" style=3D"col=
or: rgb(0, 0, 0);"><br></span><span class=3D"styled-by-prettify" style=3D"c=
olor: rgb(102, 102, 0);">}</span></div></code></div><code class=3D"prettypr=
int"><span class=3D"styled-by-prettify" style=3D"color: rgb(102, 102, 0);">=
</span></code><br>or like this:<br><br><div class=3D"prettyprint" style=3D"=
border: 1px solid rgb(187, 187, 187); border-image: none; background-color:=
 rgb(250, 250, 250); overflow-wrap: break-word;"><code class=3D"prettyprint=
"><div class=3D"subprettyprint"><span class=3D"styled-by-prettify" style=3D=
"color: rgb(136, 0, 0);">#define</span><span class=3D"styled-by-prettify" s=
tyle=3D"color: rgb(0, 0, 0);"></span><code class=3D"prettyprint"><span clas=
s=3D"styled-by-prettify" style=3D"color: rgb(0, 0, 0);"> THE_TYPE</span><sp=
an class=3D"styled-by-prettify" style=3D"color: rgb(102, 102, 0);"></span><=
/code><span class=3D"styled-by-prettify" style=3D"color: rgb(0, 0, 0);"> st=
d</span><span class=3D"styled-by-prettify" style=3D"color: rgb(102, 102, 0)=
;">::</span><span class=3D"styled-by-prettify" style=3D"color: rgb(0, 0, 0)=
;">vector</span><span class=3D"styled-by-prettify" style=3D"color: rgb(102,=
 102, 0);">&lt;</span><span class=3D"styled-by-prettify" style=3D"color: rg=
b(0, 0, 0);">X</span><span class=3D"styled-by-prettify" style=3D"color: rgb=
(102, 102, 0);">&gt;</span><span class=3D"styled-by-prettify" style=3D"colo=
r: rgb(0, 0, 0);"><br>THE_TYPE fun</span><span class=3D"styled-by-prettify"=
 style=3D"color: rgb(102, 102, 0);">()</span><span class=3D"styled-by-prett=
ify" style=3D"color: rgb(0, 0, 0);"><br></span><span class=3D"styled-by-pre=
ttify" style=3D"color: rgb(102, 102, 0);">{</span><span class=3D"styled-by-=
prettify" style=3D"color: rgb(0, 0, 0);"><br>=C2=A0 =C2=A0 THE_TYPE v</span=
><span class=3D"styled-by-prettify" style=3D"color: rgb(102, 102, 0);">;</s=
pan><span class=3D"styled-by-prettify" style=3D"color: rgb(0, 0, 0);"><br><=
/span><span class=3D"styled-by-prettify" style=3D"color: rgb(102, 102, 0);"=
>}</span></div></code></div><br>We
 probably want the former, but it would be worth mentioning it=20
explicitly, in case some implementation tries to do a token pastin.<br><br>=
Regards,<br>&amp;rzej;=C2=A0=C2=A0</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/cf82daf4-436e-421e-b644-83ba298e3a9e%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/cf82daf4-436e-421e-b644-83ba298e3a9e=
%40isocpp.org</a>.<br />

------=_Part_5590_1311858694.1480028167149--

------=_Part_5589_740598688.1480028167149--

.

------=_Part_11807_1980722709.1480028546489
Content-Type: multipart/alternative;
 boundary="----=_Part_11808_394602872.1480028546489"

------=_Part_11808_394602872.1480028546489
Content-Type: text/plain; charset=UTF-8



On Thursday, November 24, 2016 at 2:42:47 PM UTC-8, Bjorn Reese wrote:
>
> On 11/24/2016 10:38 PM, Tony V E wrote:
>
> > IMO, decltype(return) just looks better.
> > It is more similar to what we already have.
> > It doesn't clutter the function signature (which is getting cluttered
> > with throw/noexcept, concepts/requires, contracts, ...)
>
> And it can be used in more places, like
>
>    auto c = std::max<decltype(return)>(a, b);
>
>
That is a really compelling example, mind if I use it for the 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/d9254940-419c-4ffc-a3b1-99646efba9fa%40isocpp.org.

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

<div dir=3D"ltr"><br><br>On Thursday, November 24, 2016 at 2:42:47 PM UTC-8=
, Bjorn Reese wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 11/24/2=
016 10:38 PM, Tony V E wrote:
<br>
<br>&gt; IMO, decltype(return) just looks better.
<br>&gt; It is more similar to what we already have.
<br>&gt; It doesn&#39;t clutter the function signature (which is getting cl=
uttered
<br>&gt; with throw/noexcept, concepts/requires, contracts, ...)
<br>
<br>And it can be used in more places, like
<br>
<br>=C2=A0 =C2=A0auto c =3D std::max&lt;decltype(return)&gt;(a, b);
<br>
<br></blockquote><div><br>That is a really compelling example, mind if I us=
e it for the paper? <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/d9254940-419c-4ffc-a3b1-99646efba9fa%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/d9254940-419c-4ffc-a3b1-99646efba9fa=
%40isocpp.org</a>.<br />

------=_Part_11808_394602872.1480028546489--

------=_Part_11807_1980722709.1480028546489--

.

------=_Part_6131_516083959.1480028662866
Content-Type: multipart/alternative;
 boundary="----=_Part_6132_2005910003.1480028662866"

------=_Part_6132_2005910003.1480028662866
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



On Thursday, November 24, 2016 at 2:56:07 PM UTC-8, Andrzej Krzemie=C5=84sk=
i=20
wrote:
>
>
>
> W dniu =C5=9Broda, 23 listopada 2016 17:36:56 UTC+1 u=C5=BCytkownik Avi K=
ivity=20
> napisa=C5=82:
>>
>> On 11/18/2016 06:01 PM, Avi Kivity wrote:=20
>> >=20
>> > map<foo, map<set<bar>, baz>=20
>> > complicated(...) {=20
>> >     decltype(return) ret;=20
>> >     // add stuff to ret=20
>> >     return try;=20
>> > }=20
>> >=20
>> > Instead of repeating the complicated type, refer to it via=20
>> > decltype(return).  Won't work with deduced return types, of course.=20
>> >=20
>>
>> It seems like this was favorably received.  How do I make progress with=
=20
>> this?  Is there a proposal genie I can bribe to turn it into a paper?  =
=20
>> Or at least a proposal template I can fill in?=20
>>
>> I'm afraid I won't be able to present it in person, but I'm willing to=
=20
>> work on wording (to my limited ability in the matter) if someone will=20
>> pick it up and present it.=20
>>
>
> My experience shows that it is never one proposal, but a number of=20
> iterations: you write a proposal, you receive feedback, you write a=20
> revision, you receive a second feedback, and so on, until the proposal is=
=20
> mature enough. For the initial version wording may not be necessary, but =
it=20
> would be worth to consider more nasty cases. For instance:
>
> struct X { void * p; }; // sizeof(X) =3D=3D 8
>
> std::vector<X> fun()
> {
>     struct X {}; // sizeof(X) =3D=3D 1=20
>     decltype(return) v;
>     return v;
> }
>
> The question is, should decltype(return) be exactly the same type we have=
=20
> seen in function return type, or should it be a token-by token copy paste=
=20
> of the function's return type. Or in other owrds, should it work like thi=
s:
>
> typedef std::vector<X> THE_TYPE;
> THE_TYPE fun()
> {
>     THE_TYPE v;
> }
>
> or like this:
>
> #define THE_TYPE std::vector<X>
> THE_TYPE fun()
> {
>     THE_TYPE v;
> }
>
> We probably want the former, but it would be worth mentioning it=20
> explicitly, in case some implementation tries to do a token pastin.
>
> Regards,
> &rzej; =20
>

I would definitely think that the former behavior is the one most=20
consistent with the language as it is.  This is something that proper=20
wording would take care of, something like, "the type represented by=20
dectype(return) is the actual return type of the containing function".  If=
=20
this gets through EWG, I'll definitely keep this in mind writing hte Core=
=20
paper.

--=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/8593dee5-b4b3-4d87-91b6-7502b9d985dd%40isocpp.or=
g.

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

<div dir=3D"ltr"><br><br>On Thursday, November 24, 2016 at 2:56:07 PM UTC-8=
, Andrzej Krzemie=C5=84ski 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"><br><br>W dniu =C5=9Broda, 23 listopada 2016 17:36:56 U=
TC+1 u=C5=BCytkownik Avi Kivity napisa=C5=82:<blockquote class=3D"gmail_quo=
te" style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rg=
b(204,204,204);border-left-width:1px;border-left-style:solid">On 11/18/2016=
 06:01 PM, Avi Kivity wrote:
<br>&gt;
<br>&gt; map&lt;foo, map&lt;set&lt;bar&gt;, baz&gt;
<br>&gt; complicated(...) {
<br>&gt; =C2=A0 =C2=A0 decltype(return) ret;
<br>&gt; =C2=A0 =C2=A0 // add stuff to ret
<br>&gt; =C2=A0 =C2=A0 return try;
<br>&gt; }
<br>&gt;
<br>&gt; Instead of repeating the complicated type, refer to it via=20
<br>&gt; decltype(return). =C2=A0Won&#39;t work with deduced return types, =
of course.
<br>&gt;
<br>
<br>It seems like this was favorably received. =C2=A0How do I make progress=
 with=20
<br>this? =C2=A0Is there a proposal genie I can bribe to turn it into a pap=
er? =C2=A0
<br>Or at least a proposal template I can fill in?
<br>
<br>I&#39;m afraid I won&#39;t be able to present it in person, but I&#39;m=
 willing to=20
<br>work on wording (to my limited ability in the matter) if someone will=
=20
<br>pick it up and present it.
<br></blockquote><div><br></div><div>My experience shows that it is never o=
ne=20
proposal, but a number of iterations: you write a proposal, you receive=20
feedback, you write a revision, you receive a second feedback, and so=20
on, until the proposal is mature enough. For the initial version wording
 may not be necessary, but it would be worth to consider more nasty=20
cases. For instance:<br><br><div style=3D"border:1px solid rgb(187,187,187)=
;background-color:rgb(250,250,250)"><code><div><span style=3D"color:rgb(0,0=
,136)">struct</span><span style=3D"color:rgb(0,0,0)"> X </span><span style=
=3D"color:rgb(102,102,0)">{</span><span style=3D"color:rgb(0,0,0)"> </span>=
<span style=3D"color:rgb(0,0,136)">void</span><span style=3D"color:rgb(0,0,=
0)"> </span><span style=3D"color:rgb(102,102,0)">*</span><span style=3D"col=
or:rgb(0,0,0)"> p</span><span style=3D"color:rgb(102,102,0)">;</span><span =
style=3D"color:rgb(0,0,0)"> </span><span style=3D"color:rgb(102,102,0)">};<=
/span><span style=3D"color:rgb(0,0,0)"> </span><span style=3D"color:rgb(136=
,0,0)">// sizeof(X) =3D=3D 8</span><span style=3D"color:rgb(0,0,0)"><br><br=
>std</span><span style=3D"color:rgb(102,102,0)">::</span><span style=3D"col=
or:rgb(0,0,0)">vector</span><span style=3D"color:rgb(102,102,0)">&lt;</span=
><span style=3D"color:rgb(0,0,0)">X</span><span style=3D"color:rgb(102,102,=
0)">&gt;</span><span style=3D"color:rgb(0,0,0)"> fun</span><span style=3D"c=
olor:rgb(102,102,0)">()</span><span style=3D"color:rgb(0,0,0)"><br></span><=
span style=3D"color:rgb(102,102,0)">{</span><span style=3D"color:rgb(0,0,0)=
"><br>=C2=A0 =C2=A0 </span><span style=3D"color:rgb(0,0,136)">struct</span>=
<span style=3D"color:rgb(0,0,0)"> X </span><span style=3D"color:rgb(102,102=
,0)">{};</span><span style=3D"color:rgb(0,0,0)"> </span><span style=3D"colo=
r:rgb(136,0,0)">// sizeof(X) =3D=3D 1 </span><span style=3D"color:rgb(0,0,0=
)"><br>=C2=A0 =C2=A0 </span><span style=3D"color:rgb(0,0,136)">decltype</sp=
an><span style=3D"color:rgb(102,102,0)">(</span><span style=3D"color:rgb(0,=
0,136)">return</span><span style=3D"color:rgb(102,102,0)">)</span><span sty=
le=3D"color:rgb(0,0,0)"> v</span><span style=3D"color:rgb(102,102,0)">;</sp=
an><span style=3D"color:rgb(0,0,0)"><br>=C2=A0 =C2=A0 </span><span style=3D=
"color:rgb(0,0,136)">return</span><span style=3D"color:rgb(0,0,0)"> v</span=
><span style=3D"color:rgb(102,102,0)">;</span><span style=3D"color:rgb(0,0,=
0)"><br></span><span style=3D"color:rgb(102,102,0)">}</span></div></code></=
div><br>The
 question is, should decltype(return) be exactly the same type we have=20
seen in function return type, or should it be a token-by token copy=20
paste of the function&#39;s return type. Or in other owrds, should it work=
=20
like this:<br><br><div style=3D"border:1px solid rgb(187,187,187);backgroun=
d-color:rgb(250,250,250)"><code><div><span style=3D"color:rgb(0,0,136)">typ=
edef</span><span style=3D"color:rgb(0,0,0)"> std</span><span style=3D"color=
:rgb(102,102,0)">::</span><span style=3D"color:rgb(0,0,0)">vector</span><sp=
an style=3D"color:rgb(102,102,0)">&lt;</span><span style=3D"color:rgb(0,0,0=
)">X</span><span style=3D"color:rgb(102,102,0)">&gt;</span><span style=3D"c=
olor:rgb(0,0,0)"> THE_TYPE</span><span style=3D"color:rgb(102,102,0)">;</sp=
an><span style=3D"color:rgb(0,0,0)"><br>THE_TYPE fun</span><span style=3D"c=
olor:rgb(102,102,0)">()</span><span style=3D"color:rgb(0,0,0)"><br></span><=
span style=3D"color:rgb(102,102,0)">{</span><span style=3D"color:rgb(0,0,0)=
"><br>=C2=A0 =C2=A0 THE_TYPE v</span><span style=3D"color:rgb(102,102,0)">;=
</span><span style=3D"color:rgb(0,0,0)"><br></span><span style=3D"color:rgb=
(102,102,0)">}</span></div></code></div><code><span style=3D"color:rgb(102,=
102,0)"></span></code><br>or like this:<br><br><div style=3D"border:1px sol=
id rgb(187,187,187);background-color:rgb(250,250,250)"><code><div><span sty=
le=3D"color:rgb(136,0,0)">#define</span><span style=3D"color:rgb(0,0,0)"></=
span><code><span style=3D"color:rgb(0,0,0)"> THE_TYPE</span><span style=3D"=
color:rgb(102,102,0)"></span></code><span style=3D"color:rgb(0,0,0)"> std</=
span><span style=3D"color:rgb(102,102,0)">::</span><span style=3D"color:rgb=
(0,0,0)">vector</span><span style=3D"color:rgb(102,102,0)">&lt;</span><span=
 style=3D"color:rgb(0,0,0)">X</span><span style=3D"color:rgb(102,102,0)">&g=
t;</span><span style=3D"color:rgb(0,0,0)"><br>THE_TYPE fun</span><span styl=
e=3D"color:rgb(102,102,0)">()</span><span style=3D"color:rgb(0,0,0)"><br></=
span><span style=3D"color:rgb(102,102,0)">{</span><span style=3D"color:rgb(=
0,0,0)"><br>=C2=A0 =C2=A0 THE_TYPE v</span><span style=3D"color:rgb(102,102=
,0)">;</span><span style=3D"color:rgb(0,0,0)"><br></span><span style=3D"col=
or:rgb(102,102,0)">}</span></div></code></div><br>We
 probably want the former, but it would be worth mentioning it=20
explicitly, in case some implementation tries to do a token pastin.<br><br>=
Regards,<br>&amp;rzej;=C2=A0=C2=A0</div></div></blockquote><div><br>I would=
 definitely think that the former behavior is the one most consistent with =
the language as it is.=C2=A0 This is something that proper wording would ta=
ke care of, something like, &quot;the type represented by dectype(return) i=
s the actual return type of the containing function&quot;.=C2=A0 If this ge=
ts through EWG, I&#39;ll definitely keep this in mind writing hte Core pape=
r.<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/8593dee5-b4b3-4d87-91b6-7502b9d985dd%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/8593dee5-b4b3-4d87-91b6-7502b9d985dd=
%40isocpp.org</a>.<br />

------=_Part_6132_2005910003.1480028662866--

------=_Part_6131_516083959.1480028662866--

.

------=_Part_10523_1251906906.1480167396686
Content-Type: multipart/alternative;
 boundary="----=_Part_10524_185525220.1480167396686"

------=_Part_10524_185525220.1480167396686
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi,
I like the idea very much, but please bear in mind that `return` is not a=
=20
variable. It's a keyword and the closest approximation is an operator=20
taking a single type, being [[noreturn]] and thus returning void. Thus, if=
=20
you want to be coherent, decltype(return) should be `void(*)(T)` instead of=
=20
`T`. Which is fine - you can write `paramof()` and then=20
`decltype(paramof(return))`.
Why it's important (to me, at least)? I'm working on a way to capture=20
`return` and pass it along. Double return, if you like: it's useful for=20
custom control structures, like custom for-loop. If you put this piece in=
=20
incoherently, I won't be able to specify the type of the `return` being=20
captured (or at the very least, I'll need new logic for that).
With that said, I'd welcome a version of this in the standard.
/* As for the return variable: we have the need for uninitialized variables=
=20
elsewhere (ideally even >> would be implemented that way), we have=20
placement new() to initialize it. I don't really see a problem with taking=
=20
the address of the variable-to-be-returned and then placement new-ing into=
=20
it. While theoretically it'd limit optimization (for you're taking an=20
address you didn't before), most compilers will probably eliminate the=20
entire construct. I'd be okay with `[[uninitialized]] T t;` or `T=20
__uninitialized t;` or even `std::space_for<T> spt; T& t =3D spt;`. */
Thanks,
-lorro
Thanks,
-lorro

2016. november 18., p=C3=A9ntek 17:01:41 UTC+1 id=C5=91pontban Avi Kivity a=
=20
k=C3=B6vetkez=C5=91t =C3=ADrta:
>
>
> map<foo, map<set<bar>, baz>=20
> complicated(...) {=20
>      decltype(return) ret;=20
>      // add stuff to ret=20
>      return try;=20
> }=20
>
> Instead of repeating the complicated type, refer to it via=20
> decltype(return).  Won't work with deduced return types, of course.=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/7bad1d5c-8b57-4d42-8718-44a8a1f3acd0%40isocpp.or=
g.

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

<div dir=3D"ltr">Hi,<br>I like the idea very much, but please bear in mind =
that `return` is not a variable. It&#39;s a keyword and the closest approxi=
mation is an operator taking a single type, being [[noreturn]] and thus ret=
urning void. Thus, if you want to be coherent, decltype(return) should be `=
void(*)(T)` instead of `T`. Which is fine - you can write `paramof()` and t=
hen `decltype(paramof(return))`.<br>Why it&#39;s important (to me, at least=
)? I&#39;m working on a way to capture `return` and pass it along. Double r=
eturn, if you like: it&#39;s useful for custom control structures, like cus=
tom for-loop. If you put this piece in incoherently, I won&#39;t be able to=
 specify the type of the `return` being captured (or at the very least, I&#=
39;ll need new logic for that).<br>With that said, I&#39;d welcome a versio=
n of this in the standard.<br>/* As for the return variable: we have the ne=
ed for uninitialized variables elsewhere (ideally even &gt;&gt; would be im=
plemented that way), we have placement new() to initialize it. I don&#39;t =
really see a problem with taking the address of the variable-to-be-returned=
 and then placement new-ing into it. While theoretically it&#39;d limit opt=
imization (for you&#39;re taking an address you didn&#39;t before), most co=
mpilers will probably eliminate the entire construct. I&#39;d be okay with =
`[[uninitialized]] T t;` or `T __uninitialized t;` or even `std::space_for&=
lt;T&gt; spt; T&amp; t =3D spt;`. */<br>Thanks,<br>-lorro<br>Thanks,<br>-lo=
rro<br><br>2016. november 18., p=C3=A9ntek 17:01:41 UTC+1 id=C5=91pontban A=
vi Kivity a k=C3=B6vetkez=C5=91t =C3=ADrta:<blockquote class=3D"gmail_quote=
" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding=
-left: 1ex;">
<br>map&lt;foo, map&lt;set&lt;bar&gt;, baz&gt;
<br>complicated(...) {
<br>=C2=A0 =C2=A0 =C2=A0decltype(return) ret;
<br>=C2=A0 =C2=A0 =C2=A0// add stuff to ret
<br>=C2=A0 =C2=A0 =C2=A0return try;
<br>}
<br>
<br>Instead of repeating the complicated type, refer to it via=20
<br>decltype(return). =C2=A0Won&#39;t work with deduced return types, of co=
urse.
<br>
<br></blockquote></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/7bad1d5c-8b57-4d42-8718-44a8a1f3acd0%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/7bad1d5c-8b57-4d42-8718-44a8a1f3acd0=
%40isocpp.org</a>.<br />

------=_Part_10524_185525220.1480167396686--

------=_Part_10523_1251906906.1480167396686--

.

------=_Part_9844_1487566857.1480176202804
Content-Type: multipart/alternative;
 boundary="----=_Part_9845_1860586333.1480176202804"

------=_Part_9845_1860586333.1480176202804
Content-Type: text/plain; charset=UTF-8

On Saturday, November 26, 2016 at 8:36:36 AM UTC-5, szollos...@gmail.com
wrote:
>
> Hi,
> I like the idea very much, but please bear in mind that `return` is not a
> variable. It's a keyword and the closest approximation is an operator
> taking a single type, being [[noreturn]] and thus returning void.Thus, if
> you want to be coherent, decltype(return) should be `void(*)(T)` instead of
> `T`. Which is fine - you can write `paramof()` and then
> `decltype(paramof(return))`.
>

And yet, I don't think anyone will be in any way confused by the meaning of
`decltype(return)`. Much as they're not confused by the idea of what
`decltype(auto)` means.


> Why it's important (to me, at least)? I'm working on a way to capture
> `return` and pass it along. Double return, if you like: it's useful for
> custom control structures, like custom for-loop. If you put this piece in
> incoherently, I won't be able to specify the type of the `return` being
> captured (or at the very least, I'll need new logic for that).
>

People will be more likely to need to get the type of the return value than
they will need to create "custom control structures" that require getting
the type of whatever you're capturing. So forcing people to use the long
syntax for the more common case is not the best idea.


> With that said, I'd welcome a version of this in the standard.
> /* As for the return variable: we have the need for uninitialized
> variables elsewhere (ideally even >> would be implemented that way), we
> have placement new() to initialize it. I don't really see a problem with
> taking the address of the variable-to-be-returned and then placement
> new-ing into it.
>

The problem there is that such a feature *must* affect how the standard
handles a `return` statement. If you initialize the return value object,
then issue a `return <expr>`, the only reasonable thing for the compiler to
do is destroy the return value object you initialized, then initialize it
again with `<expr>`. To do anything else would impose requirements like
copy/move assignment, as well as damage guaranteed elision.

As such, the compiler *must* have a way to know that you've initialized the
return value. And that means it must be done via some specialized syntax,
not merely getting some `void*`. Let's not make this harder on the compiler
than it needs to be.

While I appreciate the need to solve the uninitialized variable problem
generally, I think it is best to find a solution that uses higher-level,
typed functionality, not encourage the passing around of `void*`s and using
placement-`new`. We don't want to limit solutions to experts.

--
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/61943f9a-741e-4a3d-aa3c-9e4a36696d4a%40isocpp.org.

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

<div dir=3D"ltr">On Saturday, November 26, 2016 at 8:36:36 AM UTC-5, szollo=
s...@gmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr">Hi,<br>I like the idea very much, but please bear in mind that `re=
turn` is not a variable. It&#39;s a keyword and the closest approximation i=
s an operator taking a single type, being [[noreturn]] and thus returning v=
oid.Thus, if you want to be coherent, decltype(return) should be `void(*)(T=
)` instead of `T`. Which is fine - you can write `paramof()` and then `decl=
type(paramof(return))`.<br></div></blockquote><div><br>And yet, I don&#39;t=
 think anyone will be in any way confused by the meaning of `decltype(retur=
n)`. Much as they&#39;re not confused by the idea of what `decltype(auto)` =
means.<br>=C2=A0</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">Why it&#39;s important (to me, at least)? I&#39;m working on a way=
 to capture `return` and pass it along. Double return, if you like: it&#39;=
s useful for custom control structures, like custom for-loop. If you put th=
is piece in incoherently, I won&#39;t be able to specify the type of the `r=
eturn` being captured (or at the very least, I&#39;ll need new logic for th=
at).<br></div></blockquote><div><br>People will be more likely to need to g=
et the type of the return value than they will need to create &quot;custom =
control structures&quot; that require getting the type of whatever you&#39;=
re capturing. So forcing people to use the long syntax for the more common =
case is not the best idea.<br>=C2=A0</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">With that said, I&#39;d welcome a version of t=
his in the standard.<br>/* As for the return variable: we have the need for=
 uninitialized variables elsewhere (ideally even &gt;&gt; would be implemen=
ted that way), we have placement new() to initialize it. I don&#39;t really=
 see a problem with taking the address of the variable-to-be-returned and t=
hen placement new-ing into it.</div></blockquote><div><br>The problem there=
 is that such a feature <i>must</i> affect how the standard handles a `retu=
rn` statement. If you initialize the return value object, then issue a `ret=
urn &lt;expr&gt;`, the only reasonable thing for the compiler to do is dest=
roy the return value object you initialized, then initialize it again with =
`&lt;expr&gt;`. To do anything else would impose requirements like copy/mov=
e assignment, as well as damage guaranteed elision.<br><br>As such, the com=
piler <i>must</i> have a way to know that you&#39;ve initialized the return=
 value. And that means it must be done via some specialized syntax, not mer=
ely getting some `void*`. Let&#39;s not make this harder on the compiler th=
an it needs to be.<br><br>While I appreciate the need to solve the uninitia=
lized variable problem generally, I think it is best to find a solution tha=
t uses higher-level, typed functionality, not encourage the passing around =
of `void*`s and using placement-`new`. We don&#39;t want to limit solutions=
 to experts.<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/61943f9a-741e-4a3d-aa3c-9e4a36696d4a%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/61943f9a-741e-4a3d-aa3c-9e4a36696d4a=
%40isocpp.org</a>.<br />

------=_Part_9845_1860586333.1480176202804--

------=_Part_9844_1487566857.1480176202804--

.

------=_Part_4024_322573299.1480447004901
Content-Type: multipart/alternative;
 boundary="----=_Part_4025_1096379683.1480447004902"

------=_Part_4025_1096379683.1480447004902
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi,

2016. november 26., szombat 17:03:22 UTC+1 id=C5=91pontban Nicol Bolas a=20
k=C3=B6vetkez=C5=91t =C3=ADrta:
>
> On Saturday, November 26, 2016 at 8:36:36 AM UTC-5, szollos...@gmail.com=
=20
> wrote:
>>
>> Hi,
>> I like the idea very much, but please bear in mind that `return` is not =
a=20
>> variable. It's a keyword and the closest approximation is an operator=20
>> taking a single type, being [[noreturn]] and thus returning void.Thus, i=
f=20
>> you want to be coherent, decltype(return) should be `void(*)(T)` instead=
 of=20
>> `T`. Which is fine - you can write `paramof()` and then=20
>> `decltype(paramof(return))`.
>>
>
> And yet, I don't think anyone will be in any way confused by the meaning=
=20
> of `decltype(return)`. Much as they're not confused by the idea of what=
=20
> `decltype(auto)` means.
>
That's right. However,
=20

> Why it's important (to me, at least)? I'm working on a way to capture=20
>> `return` and pass it along. Double return, if you like: it's useful for=
=20
>> custom control structures, like custom for-loop. If you put this piece i=
n=20
>> incoherently, I won't be able to specify the type of the `return` being=
=20
>> captured (or at the very least, I'll need new logic for that).
>>
>
> People will be more likely to need to get the type of the return value=20
> than they will need to create "custom control structures" that require=20
> getting the type of whatever you're capturing. So forcing people to use t=
he=20
> long syntax for the more common case is not the best idea.
>
I'm unsure in this. I miss for_if / first / done / break / empty / for_map=
=20
construct literally every week in actual work. Hence I started working on=
=20
it.

> =20
>
>> With that said, I'd welcome a version of this in the standard.
>> /* As for the return variable: we have the need for uninitialized=20
>> variables elsewhere (ideally even >> would be implemented that way), we=
=20
>> have placement new() to initialize it. I don't really see a problem with=
=20
>> taking the address of the variable-to-be-returned and then placement=20
>> new-ing into it.
>>
>
> The problem there is that such a feature *must* affect how the standard=
=20
> handles a `return` statement. If you initialize the return value object,=
=20
> then issue a `return <expr>`, the only reasonable thing for the compiler =
to=20
> do is destroy the return value object you initialized, then initialize it=
=20
> again with `<expr>`. To do anything else would impose requirements like=
=20
> copy/move assignment, as well as damage guaranteed elision.
>
I expect to have either `return <expr>` or `new(&retval)T(expr)`. I'm not a=
=20
big fan of default-constructed variables & assignment to them; still, if=20
you need that, you can start your fn with `new(&retval)T()`. What brings a=
=20
real difference is that now we know the address of the return value.

As such, the compiler *must* have a way to know that you've initialized the=
=20
> return value. And that means it must be done via some specialized syntax,=
=20
> not merely getting some `void*`. Let's not make this harder on the compil=
er=20
> than it needs to be.
>
Assume it's not initialized @ function entry and it must be initialized (by=
=20
user) @ exit. Inbetween it's the programmer's responsibility to keep the=20
usual rules.
Alternative: auto fn(T t) -> [[uninitialized]] T retval { new(&retval)T(t);=
=20
}

Thanks,
-lorro

--=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/2606bf95-eb8a-4d3b-b66c-f5bbb83d7e36%40isocpp.or=
g.

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

<div dir=3D"ltr">Hi,<br><br>2016. november 26., szombat 17:03:22 UTC+1 id=
=C5=91pontban Nicol Bolas a k=C3=B6vetkez=C5=91t =C3=ADrta:<blockquote clas=
s=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #c=
cc solid;padding-left: 1ex;"><div dir=3D"ltr">On Saturday, November 26, 201=
6 at 8:36:36 AM UTC-5, <a>szollos...@gmail.com</a> 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">Hi,<br>I like the idea very much, b=
ut please bear in mind that `return` is not a variable. It&#39;s a keyword =
and the closest approximation is an operator taking a single type, being [[=
noreturn]] and thus returning void.Thus, if you want to be coherent, declty=
pe(return) should be `void(*)(T)` instead of `T`. Which is fine - you can w=
rite `paramof()` and then `decltype(paramof(return))`.<br></div></blockquot=
e><div><br>And yet, I don&#39;t think anyone will be in any way confused by=
 the meaning of `decltype(return)`. Much as they&#39;re not confused by the=
 idea of what `decltype(auto)` means.<br></div></div></blockquote><div>That=
&#39;s right. However,<br>=C2=A0<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"><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div d=
ir=3D"ltr">Why it&#39;s important (to me, at least)? I&#39;m working on a w=
ay to capture `return` and pass it along. Double return, if you like: it&#3=
9;s useful for custom control structures, like custom for-loop. If you put =
this piece in incoherently, I won&#39;t be able to specify the type of the =
`return` being captured (or at the very least, I&#39;ll need new logic for =
that).<br></div></blockquote><div><br>People will be more likely to need to=
 get the type of the return value than they will need to create &quot;custo=
m control structures&quot; that require getting the type of whatever you&#3=
9;re capturing. So forcing people to use the long syntax for the more commo=
n case is not the best idea.<br></div></div></blockquote><div>I&#39;m unsur=
e in this. I miss for_if / first / done / break / empty / for_map construct=
 literally every week in actual work. Hence I started working on it.<br></d=
iv><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>=C2=
=A0</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">With that=
 said, I&#39;d welcome a version of this in the standard.<br>/* As for the =
return variable: we have the need for uninitialized variables elsewhere (id=
eally even &gt;&gt; would be implemented that way), we have placement new()=
 to initialize it. I don&#39;t really see a problem with taking the address=
 of the variable-to-be-returned and then placement new-ing into it.</div></=
blockquote><div><br>The problem there is that such a feature <i>must</i> af=
fect how the standard handles a `return` statement. If you initialize the r=
eturn value object, then issue a `return &lt;expr&gt;`, the only reasonable=
 thing for the compiler to do is destroy the return value object you initia=
lized, then initialize it again with `&lt;expr&gt;`. To do anything else wo=
uld impose requirements like copy/move assignment, as well as damage guaran=
teed elision.<br></div></div></blockquote><div>I expect to have either `ret=
urn &lt;expr&gt;` or `new(&amp;retval)T(expr)`. I&#39;m not a big fan of de=
fault-constructed variables &amp; assignment to them; still, if you need th=
at, you can start your fn with `new(&amp;retval)T()`. What brings a real di=
fference is that now we know the address of the return value.<br><br></div>=
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bor=
der-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>As such,=
 the compiler <i>must</i> have a way to know that you&#39;ve initialized th=
e return value. And that means it must be done via some specialized syntax,=
 not merely getting some `void*`. Let&#39;s not make this harder on the com=
piler than it needs to be.<br></div></div></blockquote><div>Assume it&#39;s=
 not initialized @ function entry and it must be initialized (by user) @ ex=
it. Inbetween it&#39;s the programmer&#39;s responsibility to keep the usua=
l rules.<br>Alternative: auto fn(T t) -&gt; [[uninitialized]] T retval { ne=
w(&amp;retval)T(t); }<br><br>Thanks,<br>-lorro<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/2606bf95-eb8a-4d3b-b66c-f5bbb83d7e36%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/2606bf95-eb8a-4d3b-b66c-f5bbb83d7e36=
%40isocpp.org</a>.<br />

------=_Part_4025_1096379683.1480447004902--

------=_Part_4024_322573299.1480447004901--

.

Has anyone written or started working on a paper yet? I might be willing
to help if needed. I also might want to reference such paper...

On 2016-11-24 17:56, Andrzej Krzemie=C5=84ski wrote:
> it would be worth to consider more nasty cases. For instance:
>=20
> struct X { void * p; }; // sizeof(X) =3D=3D 8
>=20
> std::vector<X> fun()
> {
>     struct X {}; // sizeof(X) =3D=3D 1=20
>     decltype(return) v;
>     return v;
> }
>=20
> The question is, should decltype(return) be exactly the same type we have=
=20
> seen in function return type, or should it be a token-by token copy paste=
=20
> of the function's return type.

Definitely the former! I've been working on a revised proposal to
replace P0222+P0224, which would make this a very important question to
address. To wit:

  struct { int x; int y; } // note lack of name!
  foo()
  {
    ...
  }

If we had *just* P0224 (and note that MSVC already allows the above!),
naming the return type is hard=C2=B9. The proposed `decltype(return)`
provides an obvious mechanism for naming the return type... provided
that's what it actually does.

(=C2=B9 You can do it, but it requires e.g. `decltype(foo())`. Not so bad i=
n
this case with `foo` taking no arguments, but...)

I would argue that the second option - token-copying - is just *wrong*.
Especially in an example like the above, the resulting type would be
*different* from the function's return type, which is contrary to what
`decltype(return)` would appear to mean.

(On a related note, my revised version of P0222 actually uses
`decltype(return)` instead of `auto` as originally proposed.)

--=20
Matthew

--=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/5852E3B2.9040901%40gmail.com.

.

On 12/15/2016 08:40 PM, Matthew Woehlke wrote:
> Has anyone written or started working on a paper yet? I might be willing
> to help if needed. I also might want to reference such paper...


Erich Keane (copied) had a draft.

> On 2016-11-24 17:56, Andrzej Krzemie=C5=84ski wrote:
>> it would be worth to consider more nasty cases. For instance:
>>
>> struct X { void * p; }; // sizeof(X) =3D=3D 8
>>
>> std::vector<X> fun()
>> {
>>      struct X {}; // sizeof(X) =3D=3D 1
>>      decltype(return) v;
>>      return v;
>> }
>>
>> The question is, should decltype(return) be exactly the same type we hav=
e
>> seen in function return type, or should it be a token-by token copy past=
e
>> of the function's return type.
> Definitely the former! I've been working on a revised proposal to
> replace P0222+P0224, which would make this a very important question to
> address. To wit:
>
>    struct { int x; int y; } // note lack of name!
>    foo()
>    {
>      ...
>    }
>
> If we had *just* P0224 (and note that MSVC already allows the above!),
> naming the return type is hard=C2=B9. The proposed `decltype(return)`
> provides an obvious mechanism for naming the return type... provided
> that's what it actually does.
>
> (=C2=B9 You can do it, but it requires e.g. `decltype(foo())`. Not so bad=
 in
> this case with `foo` taking no arguments, but...)
>
> I would argue that the second option - token-copying - is just *wrong*.
> Especially in an example like the above, the resulting type would be
> *different* from the function's return type, which is contrary to what
> `decltype(return)` would appear to mean.
>
> (On a related note, my revised version of P0222 actually uses
> `decltype(return)` instead of `auto` as originally proposed.)
>

--=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/8c4d5db7-607d-f219-0b83-1175de390b0e%40scylladb.=
com.

.

------=_Part_697_1056213889.1482672838102
Content-Type: multipart/alternative;
 boundary="----=_Part_698_467457924.1482672838102"

------=_Part_698_467457924.1482672838102
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I think it would be more useful to be able to get the full function type as=
=20
`T(Args...)` and then extract the return type from it, as well as other=20
information.
Currently it seems possible via decltype(functionName), but it is also=20
dangerous because functionName must be correctly typed.

=D0=BF=D1=8F=D1=82=D0=BD=D0=B8=D1=86=D0=B0, 18 =D0=BD=D0=BE=D1=8F=D0=B1=D1=
=80=D1=8F 2016 =D0=B3., 19:01:41 UTC+3 =D0=BF=D0=BE=D0=BB=D1=8C=D0=B7=D0=BE=
=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C Avi Kivity =D0=BD=D0=B0=D0=BF=D0=B8=D1=
=81=D0=B0=D0=BB:
>
>
> map<foo, map<set<bar>, baz>=20
> complicated(...) {=20
>      decltype(return) ret;=20
>      // add stuff to ret=20
>      return try;=20
> }=20
>
> Instead of repeating the complicated type, refer to it via=20
> decltype(return).  Won't work with deduced return types, of course.=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/b975789f-4d4b-4b54-b4fb-056377073864%40isocpp.or=
g.

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

<div dir=3D"ltr"><div>I think it would be more useful to be able to get the=
 full function type as `T(Args...)` and then extract the return type from i=
t, as well as other information.</div><div>Currently it seems possible via =
decltype(functionName), but it is also dangerous because functionName must =
be correctly typed.</div><div><br></div>=D0=BF=D1=8F=D1=82=D0=BD=D0=B8=D1=
=86=D0=B0, 18 =D0=BD=D0=BE=D1=8F=D0=B1=D1=80=D1=8F 2016 =D0=B3., 19:01:41 U=
TC+3 =D0=BF=D0=BE=D0=BB=D1=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=
=8C Avi Kivity =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:<blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;">
<br>map&lt;foo, map&lt;set&lt;bar&gt;, baz&gt;
<br>complicated(...) {
<br>=C2=A0 =C2=A0 =C2=A0decltype(return) ret;
<br>=C2=A0 =C2=A0 =C2=A0// add stuff to ret
<br>=C2=A0 =C2=A0 =C2=A0return try;
<br>}
<br>
<br>Instead of repeating the complicated type, refer to it via=20
<br>decltype(return). =C2=A0Won&#39;t work with deduced return types, of co=
urse.
<br>
<br></blockquote></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/b975789f-4d4b-4b54-b4fb-056377073864%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/b975789f-4d4b-4b54-b4fb-056377073864=
%40isocpp.org</a>.<br />

------=_Part_698_467457924.1482672838102--

------=_Part_697_1056213889.1482672838102--

.

2016-11-18 19:01 GMT+03:00 Avi Kivity <avi@scylladb.com>:
>
> map<foo, map<set<bar>, baz>>
> complicated(...) {
>     decltype(return) ret;
>     // add stuff to ret
>     return try;
> }
>
> Instead of repeating the complicated type, refer to it via decltype(return).
> Won't work with deduced return types, of course.

Syntax sugar makes the language harder to understand. It's not the
matter of decltype(return), it the matter of huge amount of proposals
that do small tunings and simplifications... and at one day we just
suddenly understand that the C++ language became close to Perl:

while (foo ~~ { @... }) {
    return {} unless foo != bar;
    foo += $&;
} else {
    static decltype(return) var;
    var += @ + ...;
    ++ g{hello}{word}[var];
    var;
}
{}



decltype(return) does not reduce code lines, looks good only if the
function is small, motivates people to write ugly return types instead
of providing a humanreadable typedef for the result type:

using neuron_t = map<foo, map<set<bar>, baz>>;

neuron_t complicated(...) {
    neuron_t ret;
    // add stuff to ret
    return try;
}

--
Best regards,
Antony Polukhin

--
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/CAKqmYPbB4Drfrz2ZUbFnJP%2BaSwdW2AGfj%2BWVvPaP7Ge1PiyyeA%40mail.gmail.com.

.

On 25.12.2016 20:13, Antony Polukhin wrote:
> 2016-11-18 19:01 GMT+03:00 Avi Kivity <avi@scylladb.com>:
>
> decltype(return) does not reduce code lines, looks good only if the
> function is small, motivates people to write ugly return types instead
> of providing a humanreadable typedef for the result type:
>
> using neuron_t =3D map<foo, map<set<bar>, baz>>;
>
> neuron_t complicated(...) {
>     neuron_t ret;
>     // add stuff to ret
>     return try;
> }
>

```cpp
template <typename A, typename Lot, typename Of, typename Template.=20
typename Parameters>
using complicated_t =3D long_and_complicated<A, dependent_type<Lot, Of,=20
Template, Parameters>>;

template <typename A, typename Lot, typename Of, typename Template,=20
typename Parameters>
complicated_t<A, Lot, Of, Template, Parameters> complicated(=E2=80=A6)
{
     complicated_t<A, Lot, Of, Template, Parameters> ret;
     =E2=80=A6
     return ret;
}

=E2=80=A6

auto result =3D complicated(=E2=80=A6);
```

Great, now I've added a template alias now caller is going to use thanks=20
to auto, but I still have to repeat a long name unnecessarily.

--=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/aafa5023-199d-926a-dd52-23b8524d2f09%40gmail.com=
..

.

------=_Part_768_1763347773.1482694042229
Content-Type: multipart/alternative;
 boundary="----=_Part_769_48813839.1482694042229"

------=_Part_769_48813839.1482694042229
Content-Type: text/plain; charset=UTF-8



On Sunday, December 25, 2016 at 2:13:57 PM UTC-5, Antony Polukhin wrote:
>
> 2016-11-18 19:01 GMT+03:00 Avi Kivity <a...@scylladb.com <javascript:>>:
> >
> > map<foo, map<set<bar>, baz>>
> > complicated(...) {
> >     decltype(return) ret;
> >     // add stuff to ret
> >     return try;
> > }
> >
> > Instead of repeating the complicated type, refer to it via
> decltype(return).
> > Won't work with deduced return types, of course.
>
> Syntax sugar makes the language harder to understand.


No, it doesn't. `for` loops are syntactic sugar for `while` loops.
Range-based `for` loops are syntactic sugar for `for` loops over the
begin/end iterators. And technically, you could implement all of those with
`goto`.

Syntactic sugar is a good thing, when used appropriately. The question
therefore is whether this is an appropriate use of it.

Considering that we already have the ability to automatically deduce the
return type of a function based on the `return` statement, and the fact
that we can use `auto` to prevent us from having to use the typename at the
call site, `decltype(return)` is simply one more link in that chain.

We're trying to reduce pointless repetition.

decltype(return) does not reduce code lines,


That depends on how many lines it takes to enter that return type. After
all, you can use `decltype(return)` even in a function that deduces its
return type from a return statement. So that return type could be quite
lengthy.


> looks good only if the function is small,


This is also true of most `auto`-returning functions. Also, we *want*
people to write small functions.


> motivates people to write ugly return types instead of providing a
> humanreadable typedef for the result type:
>

You assume that such a typedef can actually be written. Automatic return
type deduction means that types with very complex typenames can be
returned. Not all of them can be easily predicted and culled out with a
typedef.

--
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/425f6577-b92d-40f3-8d0d-64668351edf5%40isocpp.org.

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

<div dir=3D"ltr"><br><br>On Sunday, December 25, 2016 at 2:13:57 PM UTC-5, =
Antony Polukhin wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;=
margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">2016-11-=
18 19:01 GMT+03:00 Avi Kivity &lt;<a href=3D"javascript:" target=3D"_blank"=
 gdf-obfuscated-mailto=3D"3Se-KWa-CAAJ" rel=3D"nofollow" onmousedown=3D"thi=
s.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;ja=
vascript:&#39;;return true;">a...@scylladb.com</a>&gt;:
<br>&gt;
<br>&gt; map&lt;foo, map&lt;set&lt;bar&gt;, baz&gt;&gt;
<br>&gt; complicated(...) {
<br>&gt; =C2=A0 =C2=A0 decltype(return) ret;
<br>&gt; =C2=A0 =C2=A0 // add stuff to ret
<br>&gt; =C2=A0 =C2=A0 return try;
<br>&gt; }
<br>&gt;
<br>&gt; Instead of repeating the complicated type, refer to it via decltyp=
e(return).
<br>&gt; Won&#39;t work with deduced return types, of course.
<br>
<br>Syntax sugar makes the language harder to understand.</blockquote><div>=
<br>No, it doesn&#39;t. `for` loops are syntactic sugar for `while` loops. =
Range-based `for` loops are syntactic sugar for `for` loops over the begin/=
end iterators. And technically, you could implement all of those with `goto=
`.<br><br>Syntactic sugar is a good thing, when used appropriately. The que=
stion therefore is whether this is an appropriate use of it.<br><br>Conside=
ring that we already have the ability to automatically deduce the return ty=
pe of a function based on the `return` statement, and the fact that we can =
use `auto` to prevent us from having to use the typename at the call site, =
`decltype(return)` is simply one more link in that chain.<br><br>We&#39;re =
trying to reduce pointless repetition.<br><br></div><blockquote class=3D"gm=
ail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc soli=
d;padding-left: 1ex;">decltype(return) does not reduce code lines,</blockqu=
ote><div><br>That depends on how many lines it takes to enter that return t=
ype. After all, you can use `decltype(return)` even in a function that dedu=
ces its return type from a return statement. So that return type could be q=
uite lengthy.<br>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"mar=
gin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"> =
looks good only if the
function is small,</blockquote><div><br>This is also true of most `auto`-re=
turning functions. Also, we <i>want</i> people to write small functions.<br=
>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"> motivates people=
 to write ugly return types instead
of providing a humanreadable typedef for the result type:<br></blockquote><=
div><br>You assume that such a typedef can actually be written. Automatic r=
eturn type deduction means that types with very complex typenames can be re=
turned. Not all of them can be easily predicted and culled out with a typed=
ef.<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/425f6577-b92d-40f3-8d0d-64668351edf5%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/425f6577-b92d-40f3-8d0d-64668351edf5=
%40isocpp.org</a>.<br />

------=_Part_769_48813839.1482694042229--

------=_Part_768_1763347773.1482694042229--

.

2016-12-25 22:27 GMT+03:00 Nicol Bolas <jmckesson@gmail.com>:
>
>
> On Sunday, December 25, 2016 at 2:13:57 PM UTC-5, Antony Polukhin wrote:
>>
>> 2016-11-18 19:01 GMT+03:00 Avi Kivity <a...@scylladb.com>:
>> >
>> > map<foo, map<set<bar>, baz>>
>> > complicated(...) {
>> >     decltype(return) ret;
>> >     // add stuff to ret
>> >     return try;
>> > }
>> >
>> > Instead of repeating the complicated type, refer to it via
>> > decltype(return).
>> > Won't work with deduced return types, of course.
>>
>> Syntax sugar makes the language harder to understand.
>
>
> No, it doesn't. `for` loops are syntactic sugar for `while` loops.
> Range-based `for` loops are syntactic sugar for `for` loops over the
> begin/end iterators. And technically, you could implement all of those with
> `goto`.

All that sugar exist in many popular languages. decltype(return) does not.

> That depends on how many lines it takes to enter that return type. After
> all, you can use `decltype(return)` even in a function that deduces its
> return type from a return statement. So that return type could be quite
> lengthy.

It's already hard to understand what is happening if there's multiple
chained functions with auto return type. Adding decltype(return) may
make the things wose.

>> motivates people to write ugly return types instead of providing a
>> humanreadable typedef for the result type:
>
>
> You assume that such a typedef can actually be written. Automatic return
> type deduction means that types with very complex typenames can be returned.
> Not all of them can be easily predicted and culled out with a typedef.

Could you give an example?

--
Best regards,
Antony Polukhin

--
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/CAKqmYPag-x0esrhJg7vjerjtQA7GJyN4KycqtOh9%2B202P4YGRg%40mail.gmail.com.

.

2016-12-25 22:20 GMT+03:00 Jonathan M=C3=BCller <jonathanmueller.dev@gmail.=
com>:
> On 25.12.2016 20:13, Antony Polukhin wrote:
>>
>> 2016-11-18 19:01 GMT+03:00 Avi Kivity <avi@scylladb.com>:
>>
>> decltype(return) does not reduce code lines, looks good only if the
>> function is small, motivates people to write ugly return types instead
>> of providing a humanreadable typedef for the result type:
>>
>> using neuron_t =3D map<foo, map<set<bar>, baz>>;
>>
>> neuron_t complicated(...) {
>>     neuron_t ret;
>>     // add stuff to ret
>>     return try;
>> }
>>
>
> ```cpp
> template <typename A, typename Lot, typename Of, typename Template. typen=
ame
> Parameters>
> using complicated_t =3D long_and_complicated<A, dependent_type<Lot, Of,
> Template, Parameters>>;
>
> template <typename A, typename Lot, typename Of, typename Template, typen=
ame
> Parameters>
> complicated_t<A, Lot, Of, Template, Parameters> complicated(=E2=80=A6)
> {
>     complicated_t<A, Lot, Of, Template, Parameters> ret;
>     =E2=80=A6
>     return ret;
> }
>
> =E2=80=A6
>
> auto result =3D complicated(=E2=80=A6);
> ```
>
> Great, now I've added a template alias now caller is going to use thanks =
to
> auto, but I still have to repeat a long name unnecessarily.

How often do you have such cases? Adding a core language construction
for cases that occur once a year does not seem right to me.

--=20
Best regards,
Antony Polukhin

--=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/CAKqmYPZyhByeiM0D9Y%3DT%2B_NL8DU1%2BxH5h1nSaMte2=
gt%3DJBb7Uw%40mail.gmail.com.

.

Em ter=C3=A7a-feira, 27 de dezembro de 2016, =C3=A0s 08:43:08 BRST, Antony =
Polukhin=20
escreveu:
> It's already hard to understand what is happening if there's multiple
> chained functions with auto return type. Adding decltype(return) may
> make the things wose.

That's not the language's fault. We shouldn't forego adding something usefu=
l=20
because someone might misuse it and make their bad code worse.

--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--=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/1744646.rJduqo9BfR%40tjmaciei-mobl1.

.

------=_Part_1043_1940871803.1482851085850
Content-Type: multipart/alternative;
 boundary="----=_Part_1044_2021313351.1482851085850"

------=_Part_1044_2021313351.1482851085850
Content-Type: text/plain; charset=UTF-8

On Tuesday, December 27, 2016 at 12:43:11 AM UTC-5, Antony Polukhin wrote:
>
> 2016-12-25 22:27 GMT+03:00 Nicol Bolas <jmck...@gmail.com <javascript:>>:
> >
> >
> > On Sunday, December 25, 2016 at 2:13:57 PM UTC-5, Antony Polukhin wrote:
> >>
> >> 2016-11-18 19:01 GMT+03:00 Avi Kivity <a...@scylladb.com>:
> >> >
> >> > map<foo, map<set<bar>, baz>>
> >> > complicated(...) {
> >> >     decltype(return) ret;
> >> >     // add stuff to ret
> >> >     return try;
> >> > }
> >> >
> >> > Instead of repeating the complicated type, refer to it via
> >> > decltype(return).
> >> > Won't work with deduced return types, of course.
> >>
> >> Syntax sugar makes the language harder to understand.
> >
> >
> > No, it doesn't. `for` loops are syntactic sugar for `while` loops.
> > Range-based `for` loops are syntactic sugar for `for` loops over the
> > begin/end iterators. And technically, you could implement all of those
> with
> > `goto`.
>
> All that sugar exist in many popular languages. decltype(return) does not.
>

My overall point was that your statement "Syntax sugar makes the language
harder to understand," is wrong.

"many popular languages" don't have typenames that are as large as C++
typenames can get. What other languages do or don't do is not by itself
sufficient justification for what C++ should do or not do.

You can argue that it makes code harder to understand. I don't agree that
this is sufficient to warrant not having this feature, but you can argue
it. But arguing that we shouldn't have feature just because other languages
don't doesn't make sense. We're not making "many popular languages"; we're
making C++.

Languages are not supposed to be carbon copies of each other.

> That depends on how many lines it takes to enter that return type. After
> > all, you can use `decltype(return)` even in a function that deduces its
> > return type from a return statement. So that return type could be quite
> > lengthy.
>
> It's already hard to understand what is happening if there's multiple
> chained functions with auto return type. Adding decltype(return) may
> make the things wose.
>
> >> motivates people to write ugly return types instead of providing a
> >> humanreadable typedef for the result type:
> >
> >
> > You assume that such a typedef can actually be written. Automatic return
> > type deduction means that types with very complex typenames can be
> returned.
> > Not all of them can be easily predicted and culled out with a typedef.
>
> Could you give an example?
>

A lot of the stuff in Boost.Spirit, for example. What is the return type of
a complex expression of Spirit parsers?

--
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/0cfcac6f-4d8a-40f2-9fc7-cf82c65db117%40isocpp.org.

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

<div dir=3D"ltr">On Tuesday, December 27, 2016 at 12:43:11 AM UTC-5, Antony=
 Polukhin wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">2016-12-25 22:=
27 GMT+03:00 Nicol Bolas &lt;<a href=3D"javascript:" target=3D"_blank" gdf-=
obfuscated-mailto=3D"LcXw51AvCQAJ" rel=3D"nofollow" onmousedown=3D"this.hre=
f=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascr=
ipt:&#39;;return true;">jmck...@gmail.com</a>&gt;:
<br>&gt;
<br>&gt;
<br>&gt; On Sunday, December 25, 2016 at 2:13:57 PM UTC-5, Antony Polukhin =
wrote:
<br>&gt;&gt;
<br>&gt;&gt; 2016-11-18 19:01 GMT+03:00 Avi Kivity &lt;<a>a...@scylladb.com=
</a>&gt;:
<br>&gt;&gt; &gt;
<br>&gt;&gt; &gt; map&lt;foo, map&lt;set&lt;bar&gt;, baz&gt;&gt;
<br>&gt;&gt; &gt; complicated(...) {
<br>&gt;&gt; &gt; =C2=A0 =C2=A0 decltype(return) ret;
<br>&gt;&gt; &gt; =C2=A0 =C2=A0 // add stuff to ret
<br>&gt;&gt; &gt; =C2=A0 =C2=A0 return try;
<br>&gt;&gt; &gt; }
<br>&gt;&gt; &gt;
<br>&gt;&gt; &gt; Instead of repeating the complicated type, refer to it vi=
a
<br>&gt;&gt; &gt; decltype(return).
<br>&gt;&gt; &gt; Won&#39;t work with deduced return types, of course.
<br>&gt;&gt;
<br>&gt;&gt; Syntax sugar makes the language harder to understand.
<br>&gt;
<br>&gt;
<br>&gt; No, it doesn&#39;t. `for` loops are syntactic sugar for `while` lo=
ops.
<br>&gt; Range-based `for` loops are syntactic sugar for `for` loops over t=
he
<br>&gt; begin/end iterators. And technically, you could implement all of t=
hose with
<br>&gt; `goto`.
<br>
<br>All that sugar exist in many popular languages. decltype(return) does n=
ot.<br></blockquote><div><br>My overall point was that your statement &quot=
;Syntax sugar makes the language harder to understand,&quot; is wrong.<br><=
br>&quot;many popular languages&quot; don&#39;t have typenames that are as =
large as C++ typenames can get. What other languages do or don&#39;t do is =
not by itself sufficient justification for what C++ should do or not do.<br=
><br>You can argue that it makes code harder to understand. I don&#39;t agr=
ee that this is sufficient to warrant not having this feature, but you can =
argue it. But arguing that we shouldn&#39;t have feature just because other=
 languages don&#39;t doesn&#39;t make sense. We&#39;re not making &quot;man=
y popular languages&quot;; we&#39;re making C++.<br><br>Languages are not s=
upposed to be carbon copies of each other.<br><br></div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;">
&gt; That depends on how many lines it takes to enter that return type. Aft=
er
<br>&gt; all, you can use `decltype(return)` even in a function that deduce=
s its
<br>&gt; return type from a return statement. So that return type could be =
quite
<br>&gt; lengthy.
<br>
<br>It&#39;s already hard to understand what is happening if there&#39;s mu=
ltiple
<br>chained functions with auto return type. Adding decltype(return) may
<br>make the things wose.
<br>
<br>&gt;&gt; motivates people to write ugly return types instead of providi=
ng a
<br>&gt;&gt; humanreadable typedef for the result type:
<br>&gt;
<br>&gt;
<br>&gt; You assume that such a typedef can actually be written. Automatic =
return
<br>&gt; type deduction means that types with very complex typenames can be=
 returned.
<br>&gt; Not all of them can be easily predicted and culled out with a type=
def.
<br>
<br>Could you give an example?<br></blockquote><div><br>A lot of the stuff =
in Boost.Spirit, for example. What is the return type of a complex expressi=
on of Spirit parsers?<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/0cfcac6f-4d8a-40f2-9fc7-cf82c65db117%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/0cfcac6f-4d8a-40f2-9fc7-cf82c65db117=
%40isocpp.org</a>.<br />

------=_Part_1044_2021313351.1482851085850--

------=_Part_1043_1940871803.1482851085850--

.

On 12/27/2016 07:43 AM, Antony Polukhin wrote:
> 2016-12-25 22:27 GMT+03:00 Nicol Bolas <jmckesson@gmail.com>:
>>
>> On Sunday, December 25, 2016 at 2:13:57 PM UTC-5, Antony Polukhin wrote:
>>> 2016-11-18 19:01 GMT+03:00 Avi Kivity <a...@scylladb.com>:
>>>> map<foo, map<set<bar>, baz>>
>>>> complicated(...) {
>>>>      decltype(return) ret;
>>>>      // add stuff to ret
>>>>      return try;
>>>> }
>>>>
>>>> Instead of repeating the complicated type, refer to it via
>>>> decltype(return).
>>>> Won't work with deduced return types, of course.
>>> Syntax sugar makes the language harder to understand.
>>
>> No, it doesn't. `for` loops are syntactic sugar for `while` loops.
>> Range-based `for` loops are syntactic sugar for `for` loops over the
>> begin/end iterators. And technically, you could implement all of those with
>> `goto`.
> All that sugar exist in many popular languages. decltype(return) does not.
>

This sugar supports the "Don't Repeat Yourself" principle, making the
code easier to understand in some cases.  Instead of parsing a long type
name twice, then understanding there is no difference, or following a
layer of indirection that was added just for the purpose, the reader
immediately sees that the type is exactly equivalent to the return
type.  The syntax is intuitive so anyone who isn't a language lawyer
immediately understands what it means.

The syntax can be misused, of course, but this is C++, not Python.
Anything in C++ can be misused.

--
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/1fa7bd40-012e-e4b5-f318-5ac96ac24cdb%40scylladb.com.

.

On 2016-12-27 00:43, Antony Polukhin wrote:
> On 2016-12-25 22:27 GMT+03:00 Nicol Bolas wrote:
>> You assume that such a typedef can actually be written. Automatic return
>> type deduction means that types with very complex typenames can be returned.
>> Not all of them can be easily predicted and culled out with a typedef.
>
> Could you give an example?

  template <typename A, typename B>
  auto foo(A a, B b, ...) -> decltype(a * b)
  { ... }

How would you write a typedef of that? Assume that `A` and/or `B`
*cannot be default constructed*.

That particular example can probably be named in the function itself
without too much difficulty, but imagine the return type is less simple,
but still argument dependent in a similar manner...

--
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/5863DB05.3030805%40gmail.com.

.

On 28 December 2016 at 17:32, Matthew Woehlke <mwoehlke.floss@gmail.com> wrote:
>   template <typename A, typename B>
>   auto foo(A a, B b, ...) -> decltype(a * b)
>   { ... }
>
> How would you write a typedef of that? Assume that `A` and/or `B`
> *cannot be default constructed*.

template <class A, class B> using ab_prod = decltype(declval<A>() *
declval<B>());

--
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/CAFk2RUYEC4z8iMvmFSS_ksqvd8-XBhNemcqW_oaoU2AMjp_0bg%40mail.gmail.com.

.

------=_Part_1745_2081005878.1483035024449
Content-Type: multipart/alternative;
 boundary="----=_Part_1746_737530553.1483035024450"

------=_Part_1746_737530553.1483035024450
Content-Type: text/plain; charset=UTF-8

On Wednesday, December 28, 2016 at 4:42:42 PM UTC+1, Ville Voutilainen
wrote:
>
> On 28 December 2016 at 17:32, Matthew Woehlke <mwoehlk...@gmail.com
> <javascript:>> wrote:
> >   template <typename A, typename B>
> >   auto foo(A a, B b, ...) -> decltype(a * b)
> >   { ... }
> >
> > How would you write a typedef of that? Assume that `A` and/or `B`
> > *cannot be default constructed*.
>
> template <class A, class B> using ab_prod = decltype(declval<A>() *
> declval<B>());
>

This does not look equivalent to me, declval<A&> would be closer.

--
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/f37c320c-b41b-4f03-b371-acdb496c05ee%40isocpp.org.

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

<div dir=3D"ltr">On Wednesday, December 28, 2016 at 4:42:42 PM UTC+1, Ville=
 Voutilainen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 28 Decem=
ber 2016 at 17:32, Matthew Woehlke &lt;<a href=3D"javascript:" target=3D"_b=
lank" gdf-obfuscated-mailto=3D"Jx80pZyeCQAJ" rel=3D"nofollow" onmousedown=
=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D=
&#39;javascript:&#39;;return true;">mwoehlk...@gmail.com</a>&gt; wrote:
<br>&gt; =C2=A0 template &lt;typename A, typename B&gt;
<br>&gt; =C2=A0 auto foo(A a, B b, ...) -&gt; decltype(a * b)
<br>&gt; =C2=A0 { ... }
<br>&gt;
<br>&gt; How would you write a typedef of that? Assume that `A` and/or `B`
<br>&gt; *cannot be default constructed*.
<br>
<br>template &lt;class A, class B&gt; using ab_prod =3D decltype(declval&lt=
;A&gt;() *
<br>declval&lt;B&gt;());
<br></blockquote><div><br>This does not look equivalent to me, declval&lt;A=
&amp;&gt; would be closer.<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/f37c320c-b41b-4f03-b371-acdb496c05ee%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/f37c320c-b41b-4f03-b371-acdb496c05ee=
%40isocpp.org</a>.<br />

------=_Part_1746_737530553.1483035024450--

------=_Part_1745_2081005878.1483035024449--

.

On 29 December 2016 at 20:10, Marc <marc.glisse@gmail.com> wrote:
> On Wednesday, December 28, 2016 at 4:42:42 PM UTC+1, Ville Voutilainen
> wrote:
>>
>> On 28 December 2016 at 17:32, Matthew Woehlke <mwoehlk...@gmail.com>
>> wrote:
>> >   template <typename A, typename B>
>> >   auto foo(A a, B b, ...) -> decltype(a * b)
>> >   { ... }
>> >
>> > How would you write a typedef of that? Assume that `A` and/or `B`
>> > *cannot be default constructed*.
>>
>> template <class A, class B> using ab_prod = decltype(declval<A>() *
>> declval<B>());
>
>
> This does not look equivalent to me, declval<A&> would be closer.


Probably. The point being that whether a type is or is not
default-constructible doesn't
hurt the ability to write such a typedef.

--
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/CAFk2RUbmHo7zVd1AgpNHMgncJkfFq4EB_JVX10LOK3E1BTSP8A%40mail.gmail.com.

.

------=_Part_1568_525870958.1483441918055
Content-Type: multipart/alternative;
 boundary="----=_Part_1569_1152792634.1483441918055"

------=_Part_1569_1152792634.1483441918055
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I like that syntax! I was thinking of something like that for a=20
hypothetical multiple return types feature

On Wednesday, November 23, 2016 at 1:50:46 AM UTC-8, Andrzej Krzemie=C5=84s=
ki=20
wrote:
>
>
>
> W dniu pi=C4=85tek, 18 listopada 2016 17:01:41 UTC+1 u=C5=BCytkownik Avi =
Kivity=20
> napisa=C5=82:
>>
>>
>> map<foo, map<set<bar>, baz>=20
>> complicated(...) {=20
>>      decltype(return) ret;=20
>>      // add stuff to ret=20
>>      return try;=20
>> }=20
>>
>> Instead of repeating the complicated type, refer to it via=20
>> decltype(return).  Won't work with deduced return types, of course.=20
>>
>
> In your example, you use this hypothetical feature to create up front the=
=20
> value you will be returning. I wonder if this is the only use case that=
=20
> drives your feature, because if so, you could consider an alternative=20
> feature: give a variable name in the place where you declare the return=
=20
> type:
>
> auto complicated(...) -> map<foo, map<set<bar>, baz> ret // ret is a=20
> "return variable"
> {=20
>   // add stuff to ret=20
> } // no return statement is ok: we have an implicit return variable=20
>
> Of course, your solution is more general, it also covers other cases:
>
> map<foo, map<set<bar>, baz>=20
> complicated(...)
> {=20
>   decltype(return) a, b;=20
>   // populate a and b
>   if (is_better(a, b))
>     return a;=20
>   else
>     return b;
> }=20
>
> Regards,
> &rzej;
>

--=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/472f6f03-51f3-4fb9-b008-10a22f419a0a%40isocpp.or=
g.

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

<div dir=3D"ltr">I like that syntax! I was thinking of something like that =
for a hypothetical multiple return types feature<br><br>On Wednesday, Novem=
ber 23, 2016 at 1:50:46 AM UTC-8, Andrzej Krzemie=C5=84ski wrote:<blockquot=
e class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: =
1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><br><br>W dniu pi=C4=85=
tek, 18 listopada 2016 17:01:41 UTC+1 u=C5=BCytkownik Avi Kivity napisa=C5=
=82:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;b=
order-left:1px #ccc solid;padding-left:1ex">
<br>map&lt;foo, map&lt;set&lt;bar&gt;, baz&gt;
<br>complicated(...) {
<br>=C2=A0 =C2=A0 =C2=A0decltype(return) ret;
<br>=C2=A0 =C2=A0 =C2=A0// add stuff to ret
<br>=C2=A0 =C2=A0 =C2=A0return try;
<br>}
<br>
<br>Instead of repeating the complicated type, refer to it via=20
<br>decltype(return). =C2=A0Won&#39;t work with deduced return types, of co=
urse.
<br></blockquote><div><br>In your example, you use this hypothetical featur=
e to create up front the value you will be returning. I wonder if this is t=
he only use case that drives your feature, because if so, you could conside=
r an alternative feature: give a variable name in the place where you decla=
re the return type:<br><br><div style=3D"background-color:rgb(250,250,250);=
border-color:rgb(187,187,187);border-style:solid;border-width:1px"><code><d=
iv><span style=3D"color:#008">auto</span><span style=3D"color:#000"> compli=
cated</span><span style=3D"color:#660">(...)</span><span style=3D"color:#00=
0"> </span><span style=3D"color:#660">-&gt;</span><span style=3D"color:#000=
"> </span><span style=3D"color:#000"><code><span style=3D"color:#000">map</=
span><span style=3D"color:#660">&lt;</span><span style=3D"color:#000">foo</=
span><span style=3D"color:#660">,</span><span style=3D"color:#000"> map</sp=
an><span style=3D"color:#660">&lt;</span><span style=3D"color:#008">set</sp=
an><span style=3D"color:#080">&lt;bar&gt;</span><span style=3D"color:#660">=
,</span><span style=3D"color:#000"> baz</span><span style=3D"color:#660">&g=
t;</span><span style=3D"color:#000"> </span><span style=3D"color:#000"></sp=
an></code>ret // ret is a &quot;return variable&quot;<br></span><span style=
=3D"color:#660">{</span><span style=3D"color:#000"> </span><span style=3D"c=
olor:#000"><br>=C2=A0 </span><span style=3D"color:#800">// add stuff to ret=
 </span><span style=3D"color:#000"></span><span style=3D"color:#000"><br></=
span><span style=3D"color:#660">} // no return statement is ok: we have an =
implicit return variable</span><span style=3D"color:#000"> </span></div></c=
ode></div><br>Of course, your solution is more general, it also covers othe=
r cases:<br><br><div style=3D"background-color:rgb(250,250,250);border-colo=
r:rgb(187,187,187);border-style:solid;border-width:1px"><code><div>map&lt;f=
oo, map&lt;set&lt;bar&gt;, baz&gt;
<br>complicated(...)<br> {
<br>=C2=A0 decltype(return) a, b;
<br>=C2=A0 // populate a and b<br>=C2=A0 if (is_better(a, b))<br>=C2=A0 =C2=
=A0 return a;
<br>=C2=A0 else<br>=C2=A0=C2=A0=C2=A0 return b;<br>}
<span style=3D"color:#660"></span></div></code></div><br>Regards,<br>&amp;r=
zej;<br></div></div></blockquote></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/472f6f03-51f3-4fb9-b008-10a22f419a0a%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/472f6f03-51f3-4fb9-b008-10a22f419a0a=
%40isocpp.org</a>.<br />

------=_Part_1569_1152792634.1483441918055--

------=_Part_1568_525870958.1483441918055--

.