------=_Part_1472_1620138779.1538430408520
Content-Type: multipart/alternative;
 boundary="----=_Part_1473_1627306069.1538430408520"

------=_Part_1473_1627306069.1538430408520
Content-Type: text/plain; charset="UTF-8"

Not sure what tone to write this in, but this is a problem that I think
needs to be addressed, and would like some feedback regarding the issue and
this proposed solution.
I also did not see this anywhere else, but if it is redundant, please let
me know.

*Currently the auto keyword is required to use a trailing return (except
with lambda functions).*
*However, auto can also be used without a trailing return to auto-deduce
the return type.*
*This can lead to errors if a trailing return is unintentionally forgotten,
which could then cause difficult to locate unintended behavior.*
*I'd like to discuss a keyword that required that the function return type
should be specified though a trailing return.*

The keyword would take on a subset of the auto keyword's behavior. Similar
to the auto keyword, it would look for the trailing return.
However, it would not auto deduce the return type if there is no trailing
return.
If no trailing return is given, then no return type would have been
specified, and a compiler error would be thrown (No return type specified).
In the case of the trailing return being "auto", it should be equivalent to
using the auto without a trailing return (to allow for consistent code
style).

The keyword would add additional specificity to the language, by allowing
programmers to better express intention.
examples:
           auto get42(){ return 42; }                               //
returns 42 as an int (possibly unintended return type)

<keyword> get42(){ return 42; }                    // compiler error, no
return type specified

           <keyword> get42()->double { return 42; }     // returns 42 as a
double (intended)

<keyword> get42()->auto { return 42; }         // returns 42 as an int
(auto return type behavior intended)


This is useful in preventing the following:

auto get42()->double { return 42; }                // Intended: returns 42
as a double

auto get42() { return 42; }                              // Unintended:
returns 42 as an int

In this case, the error is that the programmer intended to write a function
with a trailing return, but forgot the trailing return.
Everything could work fine, or unintended behavior could occur in the
program somewhere due to the different type.
The source of the unintended behavior could also be difficult to locate,
especially if the auto keyword is overused.
A similar issue can also be introduced in the case of a bad refactor, if
the return type of an auto function is unintentionally changed.

The keyword would prevent issues like this by catching such a scenario at
compile time using additional specificity.
Thus the case of a programmer unintentionally forgetting to specify a
trailing return type, can be caught at compile time, and remove a source of
difficult to locate errors.
It also increases code readability, by better expressing programmer intent.

Hopefully I've shown that such a keyword is useful, and there is just the
question of naming.
The two keywords I've thought of are "trailing" and the ever controversal
"func".
My preference is towards "func", since I think it makes code more readable.

example:  func get42()->double() { return 42; }

Unfortunately I am not sure if it would cause any name conflict issues
given the given the prevalence of the abbreviation.
It could also possibly conflict with possible future uses of func.

--
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/41781a83-d5ed-46d3-a936-da2416158846%40isocpp.org.

------=_Part_1473_1627306069.1538430408520
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Not sure what tone to write this in, but this is a pr=
oblem that I think needs to be addressed, and would like some feedback rega=
rding the issue and this proposed solution.</div><div>I also did not see th=
is anywhere else, but if it is redundant, please let me know.</div><div><br=
></div><b>Currently the auto keyword is required to use a trailing return (=
except with lambda functions).</b><div><b>However, auto can also be used wi=
thout a trailing return to auto-deduce the return type.</b></div><div><b>Th=
is can lead to errors if a trailing return is unintentionally forgotten, wh=
ich could then cause difficult to locate unintended behavior.</b></div><div=
><b>I&#39;d like to discuss a keyword that required that the function retur=
n type should be specified though a trailing return.</b></div><div><b><br><=
/b></div><div>The keyword would take on a subset of the auto keyword&#39;s =
behavior. Similar to the auto keyword, it would look for the trailing retur=
n.</div><div>However, it would not auto deduce the return type if there is =
no trailing return.=C2=A0</div><div>If no trailing return is given, then no=
 return type would have been specified, and a compiler error would be throw=
n (No return type specified).</div><div>In the case of the trailing return =
being &quot;auto&quot;, it should be equivalent to using the auto without a=
 trailing return (to allow for consistent code style).<br></div><div><br></=
div><div>The keyword would add additional specificity to the language, by a=
llowing programmers to better express intention.</div><div>examples:</div><=
div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0auto get42(){ return 42; }=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0// returns 42 as an int (possibly uninten=
ded return type)<br></div><blockquote style=3D"margin: 0 0 0 40px; border: =
none; padding: 0px;"><div>&lt;keyword&gt; get42(){ return 42; }=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // compiler err=
or, no return type specified</div></blockquote><div>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0&lt;keyword&gt; get42()-&gt;double { return 42; }=C2=A0=
 =C2=A0 =C2=A0// returns 42 as a double (intended)</div><blockquote style=
=3D"margin: 0 0 0 40px; border: none; padding: 0px;"><div>&lt;keyword&gt; g=
et42()-&gt;auto { return 42; }=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0// returns =
42 as an int (auto return type behavior intended)=C2=A0</div></blockquote><=
div><br></div><div>This is useful in preventing the following:</div><blockq=
uote style=3D"margin: 0 0 0 40px; border: none; padding: 0px;"><div>auto ge=
t42()-&gt;double { return 42; }=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 // Intended: returns 42 as a double=C2=A0</div></blockquote><=
blockquote style=3D"margin: 0 0 0 40px; border: none; padding: 0px;"><div>a=
uto get42() { return 42; }=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // Unintended: retu=
rns 42 as an int</div></blockquote><div>In this case, the error is that the=
 programmer intended to write a function with a trailing return, but forgot=
 the trailing return.</div><div>Everything could work fine, or unintended b=
ehavior could occur in the program somewhere due to the different type.</di=
v><div>The source of the unintended behavior could also be difficult to loc=
ate, especially if the auto keyword is overused.</div><div>A similar issue =
can also be introduced in the case of a bad refactor, if the return type of=
 an auto function is unintentionally changed.</div><div><br></div><div>The =
keyword would prevent issues like this by catching such a scenario at compi=
le time using additional specificity.</div><div>Thus the case of a programm=
er unintentionally forgetting to specify a trailing return type, can be cau=
ght at compile time, and remove a source of difficult to locate errors.</di=
v><div>It also increases code readability, by better expressing programmer =
intent.</div><div><br></div><div>Hopefully I&#39;ve shown that such a keywo=
rd is useful, and there is just the question of naming.</div><div>The two k=
eywords I&#39;ve thought of are &quot;trailing&quot; and the ever controver=
sal &quot;func&quot;.</div><div>My preference is towards &quot;func&quot;, =
since I think it makes code more readable.</div><blockquote style=3D"margin=
: 0 0 0 40px; border: none; padding: 0px;"><div>example:=C2=A0 func get42()=
-&gt;double() { return 42; }=C2=A0</div></blockquote><div>Unfortunately I a=
m not sure if it would cause any name conflict issues given the given the p=
revalence of the abbreviation.</div><div>It could also possibly conflict wi=
th possible future uses of func.=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/41781a83-d5ed-46d3-a936-da2416158846%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/41781a83-d5ed-46d3-a936-da2416158846=
%40isocpp.org</a>.<br />

------=_Part_1473_1627306069.1538430408520--

------=_Part_1472_1620138779.1538430408520--

.

On Tue, 2 Oct 2018 at 00:46, <alexander.graber.tilton@gmail.com> wrote:
> The keyword would add additional specificity to the language, by allowing programmers to better express intention.
> examples:
>            auto get42(){ return 42; }                               // returns 42 as an int (possibly unintended return type)
>
> <keyword> get42(){ return 42; }                    // compiler error, no return type specified
>
>            <keyword> get42()->double { return 42; }     // returns 42 as a double (intended)
>
> <keyword> get42()->auto { return 42; }         // returns 42 as an int (auto return type behavior intended)
>
>
> This is useful in preventing the following:
>
> auto get42()->double { return 42; }                // Intended: returns 42 as a double
>
> auto get42() { return 42; }                              // Unintended: returns 42 as an int

All of which I can write with a traditional return type, completely
avoiding the problem. Show me a compelling
use case where the return type must be trailing, and we'll talk.

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

.

--000000000000718d070577328499
Content-Type: text/plain; charset="UTF-8"

My understanding is that there is are already compelling use cases for
trailing returns, which is why it is part of the standard.
This is more aimed at resolving the ambiguous uses of the auto keyword,
which can be used for multiple purposes when defining a function and as
such be a contributing factor to programmer errors.
In this case the keyword is to create a more specified way to declare
programmer intention between the following use cases.
1. Declare a function with a trailing return: auto mul(T a, T b) ->
decltype(a*b){ return a*b; }
2. Automatically deduced the return type for a function: auto getChild(T
a){ return a.child(); }
Currently there is no way to express the intent of #1 without the intent of
#2
We have #2: auto-deduce return type.
We have #1 else #2: use trailing return type, else auto-deduce.
We don't have #1: use the trailing return type.

On Mon, Oct 1, 2018 at 2:51 PM Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:

> On Tue, 2 Oct 2018 at 00:46, <alexander.graber.tilton@gmail.com> wrote:
> > The keyword would add additional specificity to the language, by
> allowing programmers to better express intention.
> > examples:
> >            auto get42(){ return 42; }                               //
> returns 42 as an int (possibly unintended return type)
> >
> > <keyword> get42(){ return 42; }                    // compiler error, no
> return type specified
> >
> >            <keyword> get42()->double { return 42; }     // returns 42 as
> a double (intended)
> >
> > <keyword> get42()->auto { return 42; }         // returns 42 as an int
> (auto return type behavior intended)
> >
> >
> > This is useful in preventing the following:
> >
> > auto get42()->double { return 42; }                // Intended: returns
> 42 as a double
> >
> > auto get42() { return 42; }                              // Unintended:
> returns 42 as an int
>
> All of which I can write with a traditional return type, completely
> avoiding the problem. Show me a compelling
> use case where the return type must be trailing, and we'll talk.
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/0euDU94QGks/unsubscribe
> .
> To unsubscribe from this group and all its topics, 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/CAFk2RUbD6GqOC6XtAhDR3DVG4npXEPA4ghT_FDDHqkSCr7PO2w%40mail.gmail.com
> .
>

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFNER8RFT%3DUG1hnY1oiBp%3DO--EpNZZFZZLkPooG3T7nX6Ga3yg%40mail.gmail.com.

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

<div dir=3D"ltr">My understanding is that there is are already compelling u=
se cases for trailing returns, which is why it is part of the standard.<div=
>This is more aimed at resolving the ambiguous uses of the auto keyword, wh=
ich can be used for multiple purposes when defining a function and as such =
be a contributing factor to programmer errors.</div><div>In this case the k=
eyword is to create a more specified way to declare programmer intention be=
tween the following use cases.</div><div>1. Declare a function with a trail=
ing return:=C2=A0<span style=3D"font-family:Arial,serif">auto mul(T a, T b)=
 -&gt; decltype(a*b){=C2=A0</span><span style=3D"font-family:Arial,serif">r=
eturn a*b;=C2=A0</span><span style=3D"font-family:Arial,serif">}</span></di=
v><div>2. Automatically deduced the return type for a function:=C2=A0<span =
style=3D"font-family:Arial,serif">auto getChild(T a){=C2=A0</span><span sty=
le=3D"font-family:Arial,serif">return a.child(); }</span></div><div><span s=
tyle=3D"font-family:Arial,serif">Currently there is no way to express the i=
ntent of #1 without the intent of #2</span></div><div><span style=3D"font-f=
amily:Arial,serif">We have #2: auto-deduce return type.</span></div><div><s=
pan style=3D"font-family:Arial,serif">We have #1 else #2: use trailing retu=
rn type, else auto-deduce.</span></div><div><span style=3D"font-family:Aria=
l,serif">We don&#39;t have #1: use the trailing return type.</span></div><b=
r><div class=3D"gmail_quote"><div dir=3D"ltr">On Mon, Oct 1, 2018 at 2:51 P=
M Ville Voutilainen &lt;<a href=3D"mailto:ville.voutilainen@gmail.com">vill=
e.voutilainen@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_=
quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1=
ex">On Tue, 2 Oct 2018 at 00:46, &lt;<a href=3D"mailto:alexander.graber.til=
ton@gmail.com" target=3D"_blank">alexander.graber.tilton@gmail.com</a>&gt; =
wrote:<br>
&gt; The keyword would add additional specificity to the language, by allow=
ing programmers to better express intention.<br>
&gt; examples:<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 auto get42(){ return 42; }=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0// returns 42 as an int (possibly uninten=
ded return type)<br>
&gt;<br>
&gt; &lt;keyword&gt; get42(){ return 42; }=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // compiler error, no return type sp=
ecified<br>
&gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 &lt;keyword&gt; get42()-&gt;d=
ouble { return 42; }=C2=A0 =C2=A0 =C2=A0// returns 42 as a double (intended=
)<br>
&gt;<br>
&gt; &lt;keyword&gt; get42()-&gt;auto { return 42; }=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0// returns 42 as an int (auto return type behavior intended)<b=
r>
&gt;<br>
&gt;<br>
&gt; This is useful in preventing the following:<br>
&gt;<br>
&gt; auto get42()-&gt;double { return 42; }=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 // Intended: returns 42 as a double<br>
&gt;<br>
&gt; auto get42() { return 42; }=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // Unintende=
d: returns 42 as an int<br>
<br>
All of which I can write with a traditional return type, completely<br>
avoiding the problem. Show me a compelling<br>
use case where the return type must be trailing, and we&#39;ll talk.<br>
<br>
-- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/0euDU94QGks/unsubscribe" rel=3D"noreferr=
er" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/topic/std-pr=
oposals/0euDU94QGks/unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D"_blank">std-pr=
oposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAFk2RUbD6GqOC6XtAhDR3DVG4npXEPA4ghT_=
FDDHqkSCr7PO2w%40mail.gmail.com" rel=3D"noreferrer" target=3D"_blank">https=
://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUbD6GqOC6XtAh=
DR3DVG4npXEPA4ghT_FDDHqkSCr7PO2w%40mail.gmail.com</a>.<br>
</blockquote></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/CAFNER8RFT%3DUG1hnY1oiBp%3DO--EpNZZFZ=
ZLkPooG3T7nX6Ga3yg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFNER8RFT%3D=
UG1hnY1oiBp%3DO--EpNZZFZZLkPooG3T7nX6Ga3yg%40mail.gmail.com</a>.<br />

--000000000000718d070577328499--

.

--0000000000009f573b05773294bf
Content-Type: text/plain; charset="UTF-8"

This sounds a lot like a self-correcting declaration to me, which is...
weird? There are no other intent-checking provisions in declarations, so
why would we need one for the trailing return type?

The only motivation for *something* like this, to me, would be, if I could
*omit* the return type, but the deduction of it would still take place in a
SFINAE context, so I didn't have to *repeat* it.

My point is that the feature space is larger than just checking, and there
are competing interests in this space, where keywords are already very
scarce.

G

On Mon, Oct 1, 2018 at 6:42 PM Alexander Graber-Tilton <
alexander.graber.tilton@gmail.com> wrote:

> My understanding is that there is are already compelling use cases for
> trailing returns, which is why it is part of the standard.
> This is more aimed at resolving the ambiguous uses of the auto keyword,
> which can be used for multiple purposes when defining a function and as
> such be a contributing factor to programmer errors.
> In this case the keyword is to create a more specified way to declare
> programmer intention between the following use cases.
> 1. Declare a function with a trailing return: auto mul(T a, T b) ->
> decltype(a*b){ return a*b; }
> 2. Automatically deduced the return type for a function: auto getChild(T
> a){ return a.child(); }
> Currently there is no way to express the intent of #1 without the intent
> of #2
> We have #2: auto-deduce return type.
> We have #1 else #2: use trailing return type, else auto-deduce.
> We don't have #1: use the trailing return type.
>
> On Mon, Oct 1, 2018 at 2:51 PM Ville Voutilainen <
> ville.voutilainen@gmail.com> wrote:
>
>> On Tue, 2 Oct 2018 at 00:46, <alexander.graber.tilton@gmail.com> wrote:
>> > The keyword would add additional specificity to the language, by
>> allowing programmers to better express intention.
>> > examples:
>> >            auto get42(){ return 42; }                               //
>> returns 42 as an int (possibly unintended return type)
>> >
>> > <keyword> get42(){ return 42; }                    // compiler error,
>> no return type specified
>> >
>> >            <keyword> get42()->double { return 42; }     // returns 42
>> as a double (intended)
>> >
>> > <keyword> get42()->auto { return 42; }         // returns 42 as an int
>> (auto return type behavior intended)
>> >
>> >
>> > This is useful in preventing the following:
>> >
>> > auto get42()->double { return 42; }                // Intended: returns
>> 42 as a double
>> >
>> > auto get42() { return 42; }                              // Unintended:
>> returns 42 as an int
>>
>> All of which I can write with a traditional return type, completely
>> avoiding the problem. Show me a compelling
>> use case where the return type must be trailing, and we'll talk.
>>
>> --
>> You received this message because you are subscribed to a topic in the
>> Google Groups "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/0euDU94QGks/unsubscribe
>> .
>> To unsubscribe from this group and all its topics, 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/CAFk2RUbD6GqOC6XtAhDR3DVG4npXEPA4ghT_FDDHqkSCr7PO2w%40mail.gmail.com
>> .
>>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFNER8RFT%3DUG1hnY1oiBp%3DO--EpNZZFZZLkPooG3T7nX6Ga3yg%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFNER8RFT%3DUG1hnY1oiBp%3DO--EpNZZFZZLkPooG3T7nX6Ga3yg%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/CAANG%3DkX-d0pWd1OUrQ63X_BAb9XrVHqVAF3vORN-imRrOYqKOA%40mail.gmail.com.

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

<div dir=3D"ltr">This sounds a lot like a self-correcting declaration to me=
, which is... weird? There are no other intent-checking provisions in decla=
rations, so why would we need one for the trailing return type?<div><br></d=
iv><div>The only motivation for *something* like this, to me, would be, if =
I could *omit* the return type, but the deduction of it would still take pl=
ace in a SFINAE context, so I didn&#39;t have to *repeat* it.</div><div><br=
></div><div>My point is that the feature space is larger than just checking=
, and there are competing interests in this space, where keywords are alrea=
dy very scarce.</div><div><br></div><div>G</div></div><br><div class=3D"gma=
il_quote"><div dir=3D"ltr">On Mon, Oct 1, 2018 at 6:42 PM Alexander Graber-=
Tilton &lt;<a href=3D"mailto:alexander.graber.tilton@gmail.com">alexander.g=
raber.tilton@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_q=
uote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1e=
x"><div dir=3D"ltr">My understanding is that there is are already compellin=
g use cases for trailing returns, which is why it is part of the standard.<=
div>This is more aimed at resolving the ambiguous uses of the auto keyword,=
 which can be used for multiple purposes when defining a function and as su=
ch be a contributing factor to programmer errors.</div><div>In this case th=
e keyword is to create a more specified way to declare programmer intention=
 between the following use cases.</div><div>1. Declare a function with a tr=
ailing return:=C2=A0<span style=3D"font-family:Arial,serif">auto mul(T a, T=
 b) -&gt; decltype(a*b){=C2=A0</span><span style=3D"font-family:Arial,serif=
">return a*b;=C2=A0</span><span style=3D"font-family:Arial,serif">}</span><=
/div><div>2. Automatically deduced the return type for a function:=C2=A0<sp=
an style=3D"font-family:Arial,serif">auto getChild(T a){=C2=A0</span><span =
style=3D"font-family:Arial,serif">return a.child(); }</span></div><div><spa=
n style=3D"font-family:Arial,serif">Currently there is no way to express th=
e intent of #1 without the intent of #2</span></div><div><span style=3D"fon=
t-family:Arial,serif">We have #2: auto-deduce return type.</span></div><div=
><span style=3D"font-family:Arial,serif">We have #1 else #2: use trailing r=
eturn type, else auto-deduce.</span></div><div><span style=3D"font-family:A=
rial,serif">We don&#39;t have #1: use the trailing return type.</span></div=
><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Mon, Oct 1, 2018 at 2:5=
1 PM Ville Voutilainen &lt;<a href=3D"mailto:ville.voutilainen@gmail.com" t=
arget=3D"_blank">ville.voutilainen@gmail.com</a>&gt; wrote:<br></div><block=
quote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc=
 solid;padding-left:1ex">On Tue, 2 Oct 2018 at 00:46, &lt;<a href=3D"mailto=
:alexander.graber.tilton@gmail.com" target=3D"_blank">alexander.graber.tilt=
on@gmail.com</a>&gt; wrote:<br>
&gt; The keyword would add additional specificity to the language, by allow=
ing programmers to better express intention.<br>
&gt; examples:<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 auto get42(){ return 42; }=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0// returns 42 as an int (possibly uninten=
ded return type)<br>
&gt;<br>
&gt; &lt;keyword&gt; get42(){ return 42; }=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // compiler error, no return type sp=
ecified<br>
&gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 &lt;keyword&gt; get42()-&gt;d=
ouble { return 42; }=C2=A0 =C2=A0 =C2=A0// returns 42 as a double (intended=
)<br>
&gt;<br>
&gt; &lt;keyword&gt; get42()-&gt;auto { return 42; }=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0// returns 42 as an int (auto return type behavior intended)<b=
r>
&gt;<br>
&gt;<br>
&gt; This is useful in preventing the following:<br>
&gt;<br>
&gt; auto get42()-&gt;double { return 42; }=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 // Intended: returns 42 as a double<br>
&gt;<br>
&gt; auto get42() { return 42; }=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // Unintende=
d: returns 42 as an int<br>
<br>
All of which I can write with a traditional return type, completely<br>
avoiding the problem. Show me a compelling<br>
use case where the return type must be trailing, and we&#39;ll talk.<br>
<br>
-- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/0euDU94QGks/unsubscribe" rel=3D"noreferr=
er" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/topic/std-pr=
oposals/0euDU94QGks/unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D"_blank">std-pr=
oposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAFk2RUbD6GqOC6XtAhDR3DVG4npXEPA4ghT_=
FDDHqkSCr7PO2w%40mail.gmail.com" rel=3D"noreferrer" target=3D"_blank">https=
://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUbD6GqOC6XtAh=
DR3DVG4npXEPA4ghT_FDDHqkSCr7PO2w%40mail.gmail.com</a>.<br>
</blockquote></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" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAFNER8RFT%3DUG1hnY1oiBp%3DO--EpNZZFZ=
ZLkPooG3T7nX6Ga3yg%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfoo=
ter" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-p=
roposals/CAFNER8RFT%3DUG1hnY1oiBp%3DO--EpNZZFZZLkPooG3T7nX6Ga3yg%40mail.gma=
il.com</a>.<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/CAANG%3DkX-d0pWd1OUrQ63X_BAb9XrVHqVAF=
3vORN-imRrOYqKOA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAANG%3DkX-d0pW=
d1OUrQ63X_BAb9XrVHqVAF3vORN-imRrOYqKOA%40mail.gmail.com</a>.<br />

--0000000000009f573b05773294bf--

.

------=_Part_1499_1190244581.1538437720095
Content-Type: multipart/alternative;
 boundary="----=_Part_1500_409740092.1538437720095"

------=_Part_1500_409740092.1538437720095
Content-Type: text/plain; charset="UTF-8"

What about just extending C-syntax returns so they behave the same way as
trailing returns? It would be a potentially breaking change if a parameter
shadows another identifier at class, namespace or global scope, but I don't
think that would break much actual code, and it might even fix some subtly
incorrect code.

-Ray

On Monday, October 1, 2018 at 5:46:48 PM UTC-4, alexander.g...@gmail.com
wrote:
>
> Not sure what tone to write this in, but this is a problem that I think
> needs to be addressed, and would like some feedback regarding the issue and
> this proposed solution.
> I also did not see this anywhere else, but if it is redundant, please let
> me know.
>
> *Currently the auto keyword is required to use a trailing return (except
> with lambda functions).*
> *However, auto can also be used without a trailing return to auto-deduce
> the return type.*
> *This can lead to errors if a trailing return is unintentionally
> forgotten, which could then cause difficult to locate unintended behavior.*
> *I'd like to discuss a keyword that required that the function return type
> should be specified though a trailing return.*
>
> The keyword would take on a subset of the auto keyword's behavior. Similar
> to the auto keyword, it would look for the trailing return.
> However, it would not auto deduce the return type if there is no trailing
> return.
> If no trailing return is given, then no return type would have been
> specified, and a compiler error would be thrown (No return type specified).
> In the case of the trailing return being "auto", it should be equivalent
> to using the auto without a trailing return (to allow for consistent code
> style).
>
> The keyword would add additional specificity to the language, by allowing
> programmers to better express intention.
> examples:
>            auto get42(){ return 42; }                               //
> returns 42 as an int (possibly unintended return type)
>
> <keyword> get42(){ return 42; }                    // compiler error, no
> return type specified
>
>            <keyword> get42()->double { return 42; }     // returns 42 as a
> double (intended)
>
> <keyword> get42()->auto { return 42; }         // returns 42 as an int
> (auto return type behavior intended)
>
>
> This is useful in preventing the following:
>
> auto get42()->double { return 42; }                // Intended: returns 42
> as a double
>
> auto get42() { return 42; }                              // Unintended:
> returns 42 as an int
>
> In this case, the error is that the programmer intended to write a
> function with a trailing return, but forgot the trailing return.
> Everything could work fine, or unintended behavior could occur in the
> program somewhere due to the different type.
> The source of the unintended behavior could also be difficult to locate,
> especially if the auto keyword is overused.
> A similar issue can also be introduced in the case of a bad refactor, if
> the return type of an auto function is unintentionally changed.
>
> The keyword would prevent issues like this by catching such a scenario at
> compile time using additional specificity.
> Thus the case of a programmer unintentionally forgetting to specify a
> trailing return type, can be caught at compile time, and remove a source of
> difficult to locate errors.
> It also increases code readability, by better expressing programmer intent.
>
> Hopefully I've shown that such a keyword is useful, and there is just the
> question of naming.
> The two keywords I've thought of are "trailing" and the ever controversal
> "func".
> My preference is towards "func", since I think it makes code more readable.
>
> example:  func get42()->double() { return 42; }
>
> Unfortunately I am not sure if it would cause any name conflict issues
> given the given the prevalence of the abbreviation.
> It could also possibly conflict with possible future uses of func.
>

--
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/48e91aee-be7b-4154-8e98-9763849f8976%40isocpp.org.

------=_Part_1500_409740092.1538437720095
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>What about just extending C-syntax returns so they be=
have the same way as trailing returns? It would be a potentially breaking c=
hange if a parameter shadows another identifier at class, namespace or glob=
al scope, but I don&#39;t think that would break much actual code, and it m=
ight even fix some subtly incorrect code.</div><div><br></div><div>-Ray<br>=
</div><br>On Monday, October 1, 2018 at 5:46:48 PM UTC-4, alexander.g...@gm=
ail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"=
><div>Not sure what tone to write this in, but this is a problem that I thi=
nk needs to be addressed, and would like some feedback regarding the issue =
and this proposed solution.</div><div>I also did not see this anywhere else=
, but if it is redundant, please let me know.</div><div><br></div><b>Curren=
tly the auto keyword is required to use a trailing return (except with lamb=
da functions).</b><div><b>However, auto can also be used without a trailing=
 return to auto-deduce the return type.</b></div><div><b>This can lead to e=
rrors if a trailing return is unintentionally forgotten, which could then c=
ause difficult to locate unintended behavior.</b></div><div><b>I&#39;d like=
 to discuss a keyword that required that the function return type should be=
 specified though a trailing return.</b></div><div><b><br></b></div><div>Th=
e keyword would take on a subset of the auto keyword&#39;s behavior. Simila=
r to the auto keyword, it would look for the trailing return.</div><div>How=
ever, it would not auto deduce the return type if there is no trailing retu=
rn.=C2=A0</div><div>If no trailing return is given, then no return type wou=
ld have been specified, and a compiler error would be thrown (No return typ=
e specified).</div><div>In the case of the trailing return being &quot;auto=
&quot;, it should be equivalent to using the auto without a trailing return=
 (to allow for consistent code style).<br></div><div><br></div><div>The key=
word would add additional specificity to the language, by allowing programm=
ers to better express intention.</div><div>examples:</div><div>=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0auto get42(){ return 42; }=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0// returns 42 as an int (possibly unintended return typ=
e)<br></div><blockquote style=3D"margin:0 0 0 40px;border:none;padding:0px"=
><div>&lt;keyword&gt; get42(){ return 42; }=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // compiler error, no return type sp=
ecified</div></blockquote><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0&lt=
;keyword&gt; get42()-&gt;double { return 42; }=C2=A0 =C2=A0 =C2=A0// return=
s 42 as a double (intended)</div><blockquote style=3D"margin:0 0 0 40px;bor=
der:none;padding:0px"><div>&lt;keyword&gt; get42()-&gt;auto { return 42; }=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0// returns 42 as an int (auto return type=
 behavior intended)=C2=A0</div></blockquote><div><br></div><div>This is use=
ful in preventing the following:</div><blockquote style=3D"margin:0 0 0 40p=
x;border:none;padding:0px"><div>auto get42()-&gt;double { return 42; }=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // Intended: returns 4=
2 as a double=C2=A0</div></blockquote><blockquote style=3D"margin:0 0 0 40p=
x;border:none;padding:0px"><div>auto get42() { return 42; }=C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 // Unintended: returns 42 as an int</div></blockquote><di=
v>In this case, the error is that the programmer intended to write a functi=
on with a trailing return, but forgot the trailing return.</div><div>Everyt=
hing could work fine, or unintended behavior could occur in the program som=
ewhere due to the different type.</div><div>The source of the unintended be=
havior could also be difficult to locate, especially if the auto keyword is=
 overused.</div><div>A similar issue can also be introduced in the case of =
a bad refactor, if the return type of an auto function is unintentionally c=
hanged.</div><div><br></div><div>The keyword would prevent issues like this=
 by catching such a scenario at compile time using additional specificity.<=
/div><div>Thus the case of a programmer unintentionally forgetting to speci=
fy a trailing return type, can be caught at compile time, and remove a sour=
ce of difficult to locate errors.</div><div>It also increases code readabil=
ity, by better expressing programmer intent.</div><div><br></div><div>Hopef=
ully I&#39;ve shown that such a keyword is useful, and there is just the qu=
estion of naming.</div><div>The two keywords I&#39;ve thought of are &quot;=
trailing&quot; and the ever controversal &quot;func&quot;.</div><div>My pre=
ference is towards &quot;func&quot;, since I think it makes code more reada=
ble.</div><blockquote style=3D"margin:0 0 0 40px;border:none;padding:0px"><=
div>example:=C2=A0 func get42()-&gt;double() { return 42; }=C2=A0</div></bl=
ockquote><div>Unfortunately I am not sure if it would cause any name confli=
ct issues given the given the prevalence of the abbreviation.</div><div>It =
could also possibly conflict with possible future uses of func.=C2=A0</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/48e91aee-be7b-4154-8e98-9763849f8976%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/48e91aee-be7b-4154-8e98-9763849f8976=
%40isocpp.org</a>.<br />

------=_Part_1500_409740092.1538437720095--

------=_Part_1499_1190244581.1538437720095--

.

------=_Part_1549_1878370557.1538438189853
Content-Type: multipart/alternative;
 boundary="----=_Part_1550_1508528092.1538438189854"

------=_Part_1550_1508528092.1538438189854
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

This is somewhat aimed at a more general use case, in favor of tying to=20
have a consistent style.
There are now essentially two ways to write functions, both valid, and both=
=20
use-able in multiple scenarios.
The trailing return can be used in all scenarios, as it can be used for:=20
templates, non-templates, and lambda functions.
The traditional return style can only be used for a subset of those: some=
=20
templates, and non-templates

This means the most consistent way to write a function is using a trailing=
=20
return, yet it has a number of issues including the else auto-deduce return=
=20
type.
With the traditional style, a missing return type causes a compile error: "=
ISO=20
C++ forbids declaration of with no type"
There is no way to get a compilation error for a missing return type with=
=20
trailing return, since the "else auto-deduce" automatically kicks in.
The auto deduction leaves a space for programmer error in a way that is=20
difficult to locate, despite the fact that this is something that should be=
=20
catch-able at compile time and easily found.
So given that everything can be done using trailing returns, it makes a lot=
=20
of sense to have a way of enforcing that the return type is specified.

So the question then becomes how to specify a function that requires a=20
trailing return.
auto can't be used, since the auto-deduction is the issue.
I would have proposed something like being able to specify a trailing=20
return function without the auto keyword, but that seems odd to me, as it=
=20
doesn't match the typical way of defining things

get42()->double{return 42;} // this doesn't seem like it should be valid,=
=20
as it still has no type, but would be the alternative.=20

I don't see a way to deal with this other than a keyword.

In the end, I don't think that auto-deduction should be the default return=
=20
type for a function, and that is currently the case for any trailing return=
..
The programmer should have the option to use auto-deduction, but it=20
shouldn't be the default.



On Monday, October 1, 2018 at 3:46:51 PM UTC-7, Ga=C5=A1per A=C5=BEman wrot=
e:
>
> This sounds a lot like a self-correcting declaration to me, which is...=
=20
> weird? There are no other intent-checking provisions in declarations, so=
=20
> why would we need one for the trailing return type?
>
> The only motivation for *something* like this, to me, would be, if I coul=
d=20
> *omit* the return type, but the deduction of it would still take place in=
 a=20
> SFINAE context, so I didn't have to *repeat* it.
>
> My point is that the feature space is larger than just checking, and ther=
e=20
> are competing interests in this space, where keywords are already very=20
> scarce.
>
> G
>
> On Mon, Oct 1, 2018 at 6:42 PM Alexander Graber-Tilton <
> alexander.g...@gmail.com <javascript:>> wrote:
>
>> My understanding is that there is are already compelling use cases for=
=20
>> trailing returns, which is why it is part of the standard.
>> This is more aimed at resolving the ambiguous uses of the auto keyword,=
=20
>> which can be used for multiple purposes when defining a function and as=
=20
>> such be a contributing factor to programmer errors.
>> In this case the keyword is to create a more specified way to declare=20
>> programmer intention between the following use cases.
>> 1. Declare a function with a trailing return: auto mul(T a, T b) ->=20
>> decltype(a*b){ return a*b; }
>> 2. Automatically deduced the return type for a function: auto getChild(T=
=20
>> a){ return a.child(); }
>> Currently there is no way to express the intent of #1 without the intent=
=20
>> of #2
>> We have #2: auto-deduce return type.
>> We have #1 else #2: use trailing return type, else auto-deduce.
>> We don't have #1: use the trailing return type.
>>
>> On Mon, Oct 1, 2018 at 2:51 PM Ville Voutilainen <ville.vo...@gmail.com=
=20
>> <javascript:>> wrote:
>>
>>> On Tue, 2 Oct 2018 at 00:46, <alexander.g...@gmail.com <javascript:>>=
=20
>>> wrote:
>>> > The keyword would add additional specificity to the language, by=20
>>> allowing programmers to better express intention.
>>> > examples:
>>> >            auto get42(){ return 42; }                               /=
/=20
>>> returns 42 as an int (possibly unintended return type)
>>> >
>>> > <keyword> get42(){ return 42; }                    // compiler error,=
=20
>>> no return type specified
>>> >
>>> >            <keyword> get42()->double { return 42; }     // returns 42=
=20
>>> as a double (intended)
>>> >
>>> > <keyword> get42()->auto { return 42; }         // returns 42 as an in=
t=20
>>> (auto return type behavior intended)
>>> >
>>> >
>>> > This is useful in preventing the following:
>>> >
>>> > auto get42()->double { return 42; }                // Intended:=20
>>> returns 42 as a double
>>> >
>>> > auto get42() { return 42; }                              //=20
>>> Unintended: returns 42 as an int
>>>
>>> All of which I can write with a traditional return type, completely
>>> avoiding the problem. Show me a compelling
>>> use case where the return type must be trailing, and we'll talk.
>>>
>>> --=20
>>> You received this message because you are subscribed to a topic in the=
=20
>>> Google Groups "ISO C++ Standard - Future Proposals" group.
>>> To unsubscribe from this topic, visit=20
>>> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/0euDU94QGk=
s/unsubscribe
>>> .
>>> To unsubscribe from this group and all its topics, send an email to=20
>>> std-proposal...@isocpp.org <javascript:>.
>>> To post to this group, send email to std-pr...@isocpp.org <javascript:>=
..
>>> To view this discussion on the web visit=20
>>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUbD6=
GqOC6XtAhDR3DVG4npXEPA4ghT_FDDHqkSCr7PO2w%40mail.gmail.com
>>> .
>>>
>> --=20
>> You received this message because you are subscribed to the Google Group=
s=20
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n=20
>> email to std-proposal...@isocpp.org <javascript:>.
>> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>> To view this discussion on the web visit=20
>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFNER8RFT%=
3DUG1hnY1oiBp%3DO--EpNZZFZZLkPooG3T7nX6Ga3yg%40mail.gmail.com=20
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFNER8RFT=
%3DUG1hnY1oiBp%3DO--EpNZZFZZLkPooG3T7nX6Ga3yg%40mail.gmail.com?utm_medium=
=3Demail&utm_source=3Dfooter>
>> .
>>
>

--=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/28fd5d17-7ef4-41df-a1fd-c619a8e5d00d%40isocpp.or=
g.

------=_Part_1550_1508528092.1538438189854
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>This is somewhat aimed at a more general use case, in=
 favor of tying to have a consistent style.</div><div>There are now essenti=
ally two ways to write functions, both valid, and both use-able in multiple=
 scenarios.</div><div>The trailing return can be used in all scenarios, as =
it can be used for: templates, non-templates, and lambda functions.</div><d=
iv>The traditional return style can only be used for a subset of those: som=
e templates, and non-templates</div><div><br></div><div>This means the most=
 consistent way to write a function is using a trailing return, yet it has =
a number of issues including the else auto-deduce return type.</div><div>Wi=
th the traditional style, a missing return type causes a<font size=3D"2"> c=
ompile error:=C2=A0</font><span style=3D"font-size: small;">&quot;</span><f=
ont face=3D"arial, sans-serif" style=3D"font-size: small; margin-bottom: 0.=
5em; font-style: inherit; font-variant: inherit; font-weight: inherit; font=
-stretch: inherit; line-height: 1.35; vertical-align: baseline; box-sizing:=
 inherit; color: rgb(36, 39, 41); cursor: pointer;">ISO C++ forbids declara=
tion of with no type&quot;</font><br></div><div>There is no way to get a co=
mpilation error for a missing return type with trailing return, since the &=
quot;else auto-deduce&quot; automatically kicks in.</div><div>The auto dedu=
ction leaves a space for programmer error in a way that is difficult to loc=
ate, despite the fact that this is something that should be catch-able at c=
ompile time and easily found.<br></div><div>So given that everything can be=
 done using trailing returns, it makes a lot of sense to have a way of enfo=
rcing that the return type is specified.</div><div><br></div><div><div>So t=
he question then becomes how to specify a function that requires a trailing=
 return.</div><div>auto can&#39;t be used, since the auto-deduction is the =
issue.</div><div>I would have proposed something like being able to specify=
 a trailing return function without the auto keyword, but that seems odd to=
 me, as it doesn&#39;t match the typical way of defining things<br></div></=
div><blockquote style=3D"margin: 0 0 0 40px; border: none; padding: 0px;"><=
div>get42()-&gt;double{return 42;} // this doesn&#39;t seem like it should =
be valid, as it still has no type, but would be the alternative.=C2=A0</div=
></blockquote><div>I don&#39;t see a way to deal with this other than a key=
word.</div><div><br></div><div>In the end, I don&#39;t think that auto-dedu=
ction should be the default return type for a function, and that is current=
ly the case for any trailing return.</div><div>The programmer should have t=
he option to use auto-deduction, but it shouldn&#39;t be the default.</div>=
<div><br></div><div><br></div><br>On Monday, October 1, 2018 at 3:46:51 PM =
UTC-7, Ga=C5=A1per A=C5=BEman 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">This sounds a lot like a self-correcting declaration=
 to me, which is... weird? There are no other intent-checking provisions in=
 declarations, so why would we need one for the trailing return type?<div><=
br></div><div>The only motivation for *something* like this, to me, would b=
e, if I could *omit* the return type, but the deduction of it would still t=
ake place in a SFINAE context, so I didn&#39;t have to *repeat* it.</div><d=
iv><br></div><div>My point is that the feature space is larger than just ch=
ecking, and there are competing interests in this space, where keywords are=
 already very scarce.</div><div><br></div><div>G</div></div><br><div class=
=3D"gmail_quote"><div dir=3D"ltr">On Mon, Oct 1, 2018 at 6:42 PM Alexander =
Graber-Tilton &lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-=
mailto=3D"_oUSmH4SAgAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;ja=
vascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;r=
eturn true;">alexander.g...@<wbr>gmail.com</a>&gt; wrote:<br></div><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><div dir=3D"ltr">My understanding is that there is a=
re already compelling use cases for trailing returns, which is why it is pa=
rt of the standard.<div>This is more aimed at resolving the ambiguous uses =
of the auto keyword, which can be used for multiple purposes when defining =
a function and as such be a contributing factor to programmer errors.</div>=
<div>In this case the keyword is to create a more specified way to declare =
programmer intention between the following use cases.</div><div>1. Declare =
a function with a trailing return:=C2=A0<span style=3D"font-family:Arial,se=
rif">auto mul(T a, T b) -&gt; decltype(a*b){=C2=A0</span><span style=3D"fon=
t-family:Arial,serif">return a*b;=C2=A0</span><span style=3D"font-family:Ar=
ial,serif">}</span></div><div>2. Automatically deduced the return type for =
a function:=C2=A0<span style=3D"font-family:Arial,serif">auto getChild(T a)=
{=C2=A0</span><span style=3D"font-family:Arial,serif">return a.child(); }</=
span></div><div><span style=3D"font-family:Arial,serif">Currently there is =
no way to express the intent of #1 without the intent of #2</span></div><di=
v><span style=3D"font-family:Arial,serif">We have #2: auto-deduce return ty=
pe.</span></div><div><span style=3D"font-family:Arial,serif">We have #1 els=
e #2: use trailing return type, else auto-deduce.</span></div><div><span st=
yle=3D"font-family:Arial,serif">We don&#39;t have #1: use the trailing retu=
rn type.</span></div><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Mon=
, Oct 1, 2018 at 2:51 PM Ville Voutilainen &lt;<a href=3D"javascript:" targ=
et=3D"_blank" gdf-obfuscated-mailto=3D"_oUSmH4SAgAJ" rel=3D"nofollow" onmou=
sedown=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.h=
ref=3D&#39;javascript:&#39;;return true;">ville.vo...@gmail.com</a>&gt; wro=
te:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex">On Tue, 2 Oct 2018 at 00:46, &l=
t;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"_oUSmH=
4SAgAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&#39;;r=
eturn true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true;">ale=
xander.g...@<wbr>gmail.com</a>&gt; wrote:<br>
&gt; The keyword would add additional specificity to the language, by allow=
ing programmers to better express intention.<br>
&gt; examples:<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 auto get42(){ return 42; }=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0// returns 42 as an int (possibly uninten=
ded return type)<br>
&gt;<br>
&gt; &lt;keyword&gt; get42(){ return 42; }=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // compiler error, no return type sp=
ecified<br>
&gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 &lt;keyword&gt; get42()-&gt;d=
ouble { return 42; }=C2=A0 =C2=A0 =C2=A0// returns 42 as a double (intended=
)<br>
&gt;<br>
&gt; &lt;keyword&gt; get42()-&gt;auto { return 42; }=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0// returns 42 as an int (auto return type behavior intended)<b=
r>
&gt;<br>
&gt;<br>
&gt; This is useful in preventing the following:<br>
&gt;<br>
&gt; auto get42()-&gt;double { return 42; }=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 // Intended: returns 42 as a double<br>
&gt;<br>
&gt; auto get42() { return 42; }=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // Unintende=
d: returns 42 as an int<br>
<br>
All of which I can write with a traditional return type, completely<br>
avoiding the problem. Show me a compelling<br>
use case where the return type must be trailing, and we&#39;ll talk.<br>
<br>
-- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/0euDU94QGks/unsubscribe" rel=3D"nofollow=
" target=3D"_blank" onmousedown=3D"this.href=3D&#39;https://groups.google.c=
om/a/isocpp.org/d/topic/std-proposals/0euDU94QGks/unsubscribe&#39;;return t=
rue;" onclick=3D"this.href=3D&#39;https://groups.google.com/a/isocpp.org/d/=
topic/std-proposals/0euDU94QGks/unsubscribe&#39;;return true;">https://grou=
ps.google.com/a/<wbr>isocpp.org/d/topic/std-<wbr>proposals/0euDU94QGks/<wbr=
>unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"_oUSmH4SAgAJ" 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;">std-proposal=
....@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"_oUSmH4SAgAJ" rel=3D"nofollow" onmousedown=3D"=
this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39=
;javascript:&#39;;return true;">std-pr...@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/CAFk2RUbD6GqOC6XtAhDR3DVG4npXEPA4ghT_=
FDDHqkSCr7PO2w%40mail.gmail.com" rel=3D"nofollow" target=3D"_blank" onmouse=
down=3D"this.href=3D&#39;https://groups.google.com/a/isocpp.org/d/msgid/std=
-proposals/CAFk2RUbD6GqOC6XtAhDR3DVG4npXEPA4ghT_FDDHqkSCr7PO2w%40mail.gmail=
..com&#39;;return true;" onclick=3D"this.href=3D&#39;https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAFk2RUbD6GqOC6XtAhDR3DVG4npXEPA4ghT_=
FDDHqkSCr7PO2w%40mail.gmail.com&#39;;return true;">https://groups.google.co=
m/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/<wbr>CAFk2RUbD6GqOC6XtAhDR3D=
VG4npXE<wbr>PA4ghT_FDDHqkSCr7PO2w%40mail.<wbr>gmail.com</a>.<br>
</blockquote></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"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
_oUSmH4SAgAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&=
#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true=
;">std-proposal...@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"_oUSmH4SAgAJ" rel=3D"nofollow" onmousedown=3D"=
this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39=
;javascript:&#39;;return true;">std-pr...@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/CAFNER8RFT%3DUG1hnY1oiBp%3DO--EpNZZFZ=
ZLkPooG3T7nX6Ga3yg%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfoo=
ter" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFNER8RFT%3DUG1h=
nY1oiBp%3DO--EpNZZFZZLkPooG3T7nX6Ga3yg%40mail.gmail.com?utm_medium\x3demail=
\x26utm_source\x3dfooter&#39;;return true;" onclick=3D"this.href=3D&#39;htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFNER8RFT%3DUG1h=
nY1oiBp%3DO--EpNZZFZZLkPooG3T7nX6Ga3yg%40mail.gmail.com?utm_medium\x3demail=
\x26utm_source\x3dfooter&#39;;return true;">https://groups.google.com/a/<wb=
r>isocpp.org/d/msgid/std-<wbr>proposals/CAFNER8RFT%<wbr>3DUG1hnY1oiBp%3DO--=
<wbr>EpNZZFZZLkPooG3T7nX6Ga3yg%<wbr>40mail.gmail.com</a>.<br>
</blockquote></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/28fd5d17-7ef4-41df-a1fd-c619a8e5d00d%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/28fd5d17-7ef4-41df-a1fd-c619a8e5d00d=
%40isocpp.org</a>.<br />

------=_Part_1550_1508528092.1538438189854--

------=_Part_1549_1878370557.1538438189853--

.

------=_Part_2156_1983925698.1538541893971
Content-Type: multipart/alternative;
 boundary="----=_Part_2157_1627549421.1538541893971"

------=_Part_2157_1627549421.1538541893971
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Thinking about this further, it could also be done using static analysis,=
=20
but would then end up forcing warnings with the traditional style auto=20
return type functions.
The ambiguity comes from weather auto is indicating an auto-deduced return=
=20
type, or if it is indicating a trailing return.
The only way to check programmer error where they possibly forgot the=20
trailing return would be to warn on something like: "auto doSomething(){}"

It does make sense to have the func keyword though for this purpose, as it=
=20
would add a lot of readability to the trailing return style.
It is easier to read type and teach
{
  int i =3D 0;
  func test()->bool{return false;}
}
in comparison to:
{=20
  int i =3D 0;
  bool test(){return false;}
}

Maybe this would be better to simply revisit if there is ever a proposal=20
for a func keyword for some other reason.

On Monday, October 1, 2018 at 4:56:29 PM UTC-7, alexander.g...@gmail.com=20
wrote:
>
> This is somewhat aimed at a more general use case, in favor of tying to=
=20
> have a consistent style.
> There are now essentially two ways to write functions, both valid, and=20
> both use-able in multiple scenarios.
> The trailing return can be used in all scenarios, as it can be used for:=
=20
> templates, non-templates, and lambda functions.
> The traditional return style can only be used for a subset of those: some=
=20
> templates, and non-templates
>
> This means the most consistent way to write a function is using a trailin=
g=20
> return, yet it has a number of issues including the else auto-deduce retu=
rn=20
> type.
> With the traditional style, a missing return type causes a compile error:=
=20
> "ISO C++ forbids declaration of with no type"
> There is no way to get a compilation error for a missing return type with=
=20
> trailing return, since the "else auto-deduce" automatically kicks in.
> The auto deduction leaves a space for programmer error in a way that is=
=20
> difficult to locate, despite the fact that this is something that should =
be=20
> catch-able at compile time and easily found.
> So given that everything can be done using trailing returns, it makes a=
=20
> lot of sense to have a way of enforcing that the return type is specified=
..
>
> So the question then becomes how to specify a function that requires a=20
> trailing return.
> auto can't be used, since the auto-deduction is the issue.
> I would have proposed something like being able to specify a trailing=20
> return function without the auto keyword, but that seems odd to me, as it=
=20
> doesn't match the typical way of defining things
>
> get42()->double{return 42;} // this doesn't seem like it should be valid,=
=20
> as it still has no type, but would be the alternative.=20
>
> I don't see a way to deal with this other than a keyword.
>
> In the end, I don't think that auto-deduction should be the default retur=
n=20
> type for a function, and that is currently the case for any trailing retu=
rn.
> The programmer should have the option to use auto-deduction, but it=20
> shouldn't be the default.
>
>
>
> On Monday, October 1, 2018 at 3:46:51 PM UTC-7, Ga=C5=A1per A=C5=BEman wr=
ote:
>>
>> This sounds a lot like a self-correcting declaration to me, which is...=
=20
>> weird? There are no other intent-checking provisions in declarations, so=
=20
>> why would we need one for the trailing return type?
>>
>> The only motivation for *something* like this, to me, would be, if I=20
>> could *omit* the return type, but the deduction of it would still take=
=20
>> place in a SFINAE context, so I didn't have to *repeat* it.
>>
>> My point is that the feature space is larger than just checking, and=20
>> there are competing interests in this space, where keywords are already=
=20
>> very scarce.
>>
>> G
>>
>> On Mon, Oct 1, 2018 at 6:42 PM Alexander Graber-Tilton <
>> alexander.g...@gmail.com> wrote:
>>
>>> My understanding is that there is are already compelling use cases for=
=20
>>> trailing returns, which is why it is part of the standard.
>>> This is more aimed at resolving the ambiguous uses of the auto keyword,=
=20
>>> which can be used for multiple purposes when defining a function and as=
=20
>>> such be a contributing factor to programmer errors.
>>> In this case the keyword is to create a more specified way to declare=
=20
>>> programmer intention between the following use cases.
>>> 1. Declare a function with a trailing return: auto mul(T a, T b) ->=20
>>> decltype(a*b){ return a*b; }
>>> 2. Automatically deduced the return type for a function: auto=20
>>> getChild(T a){ return a.child(); }
>>> Currently there is no way to express the intent of #1 without the inten=
t=20
>>> of #2
>>> We have #2: auto-deduce return type.
>>> We have #1 else #2: use trailing return type, else auto-deduce.
>>> We don't have #1: use the trailing return type.
>>>
>>> On Mon, Oct 1, 2018 at 2:51 PM Ville Voutilainen <ville.vo...@gmail.com=
>=20
>>> wrote:
>>>
>>>> On Tue, 2 Oct 2018 at 00:46, <alexander.g...@gmail.com> wrote:
>>>> > The keyword would add additional specificity to the language, by=20
>>>> allowing programmers to better express intention.
>>>> > examples:
>>>> >            auto get42(){ return 42; }                             =
=20
>>>>  // returns 42 as an int (possibly unintended return type)
>>>> >
>>>> > <keyword> get42(){ return 42; }                    // compiler error=
,=20
>>>> no return type specified
>>>> >
>>>> >            <keyword> get42()->double { return 42; }     // returns 4=
2=20
>>>> as a double (intended)
>>>> >
>>>> > <keyword> get42()->auto { return 42; }         // returns 42 as an=
=20
>>>> int (auto return type behavior intended)
>>>> >
>>>> >
>>>> > This is useful in preventing the following:
>>>> >
>>>> > auto get42()->double { return 42; }                // Intended:=20
>>>> returns 42 as a double
>>>> >
>>>> > auto get42() { return 42; }                              //=20
>>>> Unintended: returns 42 as an int
>>>>
>>>> All of which I can write with a traditional return type, completely
>>>> avoiding the problem. Show me a compelling
>>>> use case where the return type must be trailing, and we'll talk.
>>>>
>>>> --=20
>>>> You received this message because you are subscribed to a topic in the=
=20
>>>> Google Groups "ISO C++ Standard - Future Proposals" group.
>>>> To unsubscribe from this topic, visit=20
>>>> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/0euDU94QG=
ks/unsubscribe
>>>> .
>>>> To unsubscribe from this group and all its topics, send an email to=20
>>>> std-proposal...@isocpp.org.
>>>> To post to this group, send email to std-pr...@isocpp.org.
>>>> To view this discussion on the web visit=20
>>>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUbD=
6GqOC6XtAhDR3DVG4npXEPA4ghT_FDDHqkSCr7PO2w%40mail.gmail.com
>>>> .
>>>>
>>> --=20
>>> You received this message because you are subscribed to the Google=20
>>> Groups "ISO C++ Standard - Future Proposals" group.
>>> To unsubscribe from this group and stop receiving emails from it, send=
=20
>>> an email to std-proposal...@isocpp.org.
>>> To post to this group, send email to std-pr...@isocpp.org.
>>> To view this discussion on the web visit=20
>>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFNER8RFT=
%3DUG1hnY1oiBp%3DO--EpNZZFZZLkPooG3T7nX6Ga3yg%40mail.gmail.com=20
>>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFNER8RF=
T%3DUG1hnY1oiBp%3DO--EpNZZFZZLkPooG3T7nX6Ga3yg%40mail.gmail.com?utm_medium=
=3Demail&utm_source=3Dfooter>
>>> .
>>>
>>

--=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/b2593726-3857-4bc4-8459-4afa527a39fa%40isocpp.or=
g.

------=_Part_2157_1627549421.1538541893971
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Thinking about this further, it could also be done using s=
tatic analysis, but would then end up forcing warnings with the traditional=
 style auto return type functions.<div>The ambiguity comes from weather aut=
o is indicating an auto-deduced return type, or if it is indicating a trail=
ing return.</div><div>The only way to check programmer error where they pos=
sibly forgot the trailing return would be to warn on something like: &quot;=
auto doSomething(){}&quot;</div><div><br></div><div>It does make sense to h=
ave the func keyword though for this purpose, as it would add a lot of read=
ability to the trailing return style.</div><div>It is easier to read type a=
nd teach</div><div>{</div><div>=C2=A0 int i =3D 0;</div><div>=C2=A0 func te=
st()-&gt;bool{return false;}</div><div>}</div><div>in comparison to:</div><=
div>{=C2=A0</div><div>=C2=A0 int i =3D 0;</div><div><div>=C2=A0 bool test()=
{return false;}</div><div>}</div></div><div><br></div><div>Maybe this would=
 be better to simply revisit if there is ever a proposal for a func keyword=
 for some other reason.</div><div><br>On Monday, October 1, 2018 at 4:56:29=
 PM UTC-7, alexander.g...@gmail.com wrote:<blockquote class=3D"gmail_quote"=
 style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-=
left: 1ex;"><div dir=3D"ltr"><div>This is somewhat aimed at a more general =
use case, in favor of tying to have a consistent style.</div><div>There are=
 now essentially two ways to write functions, both valid, and both use-able=
 in multiple scenarios.</div><div>The trailing return can be used in all sc=
enarios, as it can be used for: templates, non-templates, and lambda functi=
ons.</div><div>The traditional return style can only be used for a subset o=
f those: some templates, and non-templates</div><div><br></div><div>This me=
ans the most consistent way to write a function is using a trailing return,=
 yet it has a number of issues including the else auto-deduce return type.<=
/div><div>With the traditional style, a missing return type causes a<font s=
ize=3D"2"> compile error:=C2=A0</font><span style=3D"font-size:small">&quot=
;</span><font face=3D"arial, sans-serif" style=3D"font-size:small;margin-bo=
ttom:0.5em;font-style:inherit;font-variant:inherit;font-weight:inherit;font=
-stretch:inherit;line-height:1.35;vertical-align:baseline;color:rgb(36,39,4=
1)">ISO C++ forbids declaration of with no type&quot;</font><br></div><div>=
There is no way to get a compilation error for a missing return type with t=
railing return, since the &quot;else auto-deduce&quot; automatically kicks =
in.</div><div>The auto deduction leaves a space for programmer error in a w=
ay that is difficult to locate, despite the fact that this is something tha=
t should be catch-able at compile time and easily found.<br></div><div>So g=
iven that everything can be done using trailing returns, it makes a lot of =
sense to have a way of enforcing that the return type is specified.</div><d=
iv><br></div><div><div>So the question then becomes how to specify a functi=
on that requires a trailing return.</div><div>auto can&#39;t be used, since=
 the auto-deduction is the issue.</div><div>I would have proposed something=
 like being able to specify a trailing return function without the auto key=
word, but that seems odd to me, as it doesn&#39;t match the typical way of =
defining things<br></div></div><blockquote style=3D"margin:0 0 0 40px;borde=
r:none;padding:0px"><div>get42()-&gt;double{return 42;} // this doesn&#39;t=
 seem like it should be valid, as it still has no type, but would be the al=
ternative.=C2=A0</div></blockquote><div>I don&#39;t see a way to deal with =
this other than a keyword.</div><div><br></div><div>In the end, I don&#39;t=
 think that auto-deduction should be the default return type for a function=
, and that is currently the case for any trailing return.</div><div>The pro=
grammer should have the option to use auto-deduction, but it shouldn&#39;t =
be the default.</div><div><br></div><div><br></div><br>On Monday, October 1=
, 2018 at 3:46:51 PM UTC-7, Ga=C5=A1per A=C5=BEman 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">This sounds a lot like a self-corre=
cting declaration to me, which is... weird? There are no other intent-check=
ing provisions in declarations, so why would we need one for the trailing r=
eturn type?<div><br></div><div>The only motivation for *something* like thi=
s, to me, would be, if I could *omit* the return type, but the deduction of=
 it would still take place in a SFINAE context, so I didn&#39;t have to *re=
peat* it.</div><div><br></div><div>My point is that the feature space is la=
rger than just checking, and there are competing interests in this space, w=
here keywords are already very scarce.</div><div><br></div><div>G</div></di=
v><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Mon, Oct 1, 2018 at 6:=
42 PM Alexander Graber-Tilton &lt;<a rel=3D"nofollow">alexander.g...@gmail.=
com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"marg=
in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"=
>My understanding is that there is are already compelling use cases for tra=
iling returns, which is why it is part of the standard.<div>This is more ai=
med at resolving the ambiguous uses of the auto keyword, which can be used =
for multiple purposes when defining a function and as such be a contributin=
g factor to programmer errors.</div><div>In this case the keyword is to cre=
ate a more specified way to declare programmer intention between the follow=
ing use cases.</div><div>1. Declare a function with a trailing return:=C2=
=A0<span style=3D"font-family:Arial,serif">auto mul(T a, T b) -&gt; decltyp=
e(a*b){=C2=A0</span><span style=3D"font-family:Arial,serif">return a*b;=C2=
=A0</span><span style=3D"font-family:Arial,serif">}</span></div><div>2. Aut=
omatically deduced the return type for a function:=C2=A0<span style=3D"font=
-family:Arial,serif">auto getChild(T a){=C2=A0</span><span style=3D"font-fa=
mily:Arial,serif">return a.child(); }</span></div><div><span style=3D"font-=
family:Arial,serif">Currently there is no way to express the intent of #1 w=
ithout the intent of #2</span></div><div><span style=3D"font-family:Arial,s=
erif">We have #2: auto-deduce return type.</span></div><div><span style=3D"=
font-family:Arial,serif">We have #1 else #2: use trailing return type, else=
 auto-deduce.</span></div><div><span style=3D"font-family:Arial,serif">We d=
on&#39;t have #1: use the trailing return type.</span></div><br><div class=
=3D"gmail_quote"><div dir=3D"ltr">On Mon, Oct 1, 2018 at 2:51 PM Ville Vout=
ilainen &lt;<a rel=3D"nofollow">ville.vo...@gmail.com</a>&gt; wrote:<br></d=
iv><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left=
:1px #ccc solid;padding-left:1ex">On Tue, 2 Oct 2018 at 00:46, &lt;<a rel=
=3D"nofollow">alexander.g...@gmail.com</a>&gt; wrote:<br>
&gt; The keyword would add additional specificity to the language, by allow=
ing programmers to better express intention.<br>
&gt; examples:<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 auto get42(){ return 42; }=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0// returns 42 as an int (possibly uninten=
ded return type)<br>
&gt;<br>
&gt; &lt;keyword&gt; get42(){ return 42; }=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // compiler error, no return type sp=
ecified<br>
&gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 &lt;keyword&gt; get42()-&gt;d=
ouble { return 42; }=C2=A0 =C2=A0 =C2=A0// returns 42 as a double (intended=
)<br>
&gt;<br>
&gt; &lt;keyword&gt; get42()-&gt;auto { return 42; }=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0// returns 42 as an int (auto return type behavior intended)<b=
r>
&gt;<br>
&gt;<br>
&gt; This is useful in preventing the following:<br>
&gt;<br>
&gt; auto get42()-&gt;double { return 42; }=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 // Intended: returns 42 as a double<br>
&gt;<br>
&gt; auto get42() { return 42; }=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // Unintende=
d: returns 42 as an int<br>
<br>
All of which I can write with a traditional return type, completely<br>
avoiding the problem. Show me a compelling<br>
use case where the return type must be trailing, and we&#39;ll talk.<br>
<br>
-- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/0euDU94QGks/unsubscribe" rel=3D"nofollow=
" target=3D"_blank" onmousedown=3D"this.href=3D&#39;https://groups.google.c=
om/a/isocpp.org/d/topic/std-proposals/0euDU94QGks/unsubscribe&#39;;return t=
rue;" onclick=3D"this.href=3D&#39;https://groups.google.com/a/isocpp.org/d/=
topic/std-proposals/0euDU94QGks/unsubscribe&#39;;return true;">https://grou=
ps.google.com/a/<wbr>isocpp.org/d/topic/std-<wbr>proposals/0euDU94QGks/<wbr=
>unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a rel=
=3D"nofollow">std-proposal...@isocpp.org</a>.<br>
To post to this group, send email to <a rel=3D"nofollow">std-pr...@isocpp.o=
rg</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAFk2RUbD6GqOC6XtAhDR3DVG4npXEPA4ghT_=
FDDHqkSCr7PO2w%40mail.gmail.com" rel=3D"nofollow" target=3D"_blank" onmouse=
down=3D"this.href=3D&#39;https://groups.google.com/a/isocpp.org/d/msgid/std=
-proposals/CAFk2RUbD6GqOC6XtAhDR3DVG4npXEPA4ghT_FDDHqkSCr7PO2w%40mail.gmail=
..com&#39;;return true;" onclick=3D"this.href=3D&#39;https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAFk2RUbD6GqOC6XtAhDR3DVG4npXEPA4ghT_=
FDDHqkSCr7PO2w%40mail.gmail.com&#39;;return true;">https://groups.google.co=
m/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/<wbr>CAFk2RUbD6GqOC6XtAhDR3D=
VG4npXE<wbr>PA4ghT_FDDHqkSCr7PO2w%40mail.<wbr>gmail.com</a>.<br>
</blockquote></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 rel=3D"nofollow">std-proposal...@isocpp.org</a>.<br>
To post to this group, send email to <a rel=3D"nofollow">std-pr...@isocpp.o=
rg</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAFNER8RFT%3DUG1hnY1oiBp%3DO--EpNZZFZ=
ZLkPooG3T7nX6Ga3yg%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfoo=
ter" rel=3D"nofollow" target=3D"_blank" onmousedown=3D"this.href=3D&#39;htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFNER8RFT%3DUG1h=
nY1oiBp%3DO--EpNZZFZZLkPooG3T7nX6Ga3yg%40mail.gmail.com?utm_medium\x3demail=
\x26utm_source\x3dfooter&#39;;return true;" onclick=3D"this.href=3D&#39;htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFNER8RFT%3DUG1h=
nY1oiBp%3DO--EpNZZFZZLkPooG3T7nX6Ga3yg%40mail.gmail.com?utm_medium\x3demail=
\x26utm_source\x3dfooter&#39;;return true;">https://groups.google.com/a/<wb=
r>isocpp.org/d/msgid/std-<wbr>proposals/CAFNER8RFT%<wbr>3DUG1hnY1oiBp%3DO--=
<wbr>EpNZZFZZLkPooG3T7nX6Ga3yg%<wbr>40mail.gmail.com</a>.<br>
</blockquote></div>
</blockquote></div></blockquote></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/b2593726-3857-4bc4-8459-4afa527a39fa%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/b2593726-3857-4bc4-8459-4afa527a39fa=
%40isocpp.org</a>.<br />

------=_Part_2157_1627549421.1538541893971--

------=_Part_2156_1983925698.1538541893971--

.