Topic: auto return
Author: Andrew Tomazos <andrewtomazos@gmail.com>
Date: Tue, 29 Sep 2015 06:10:15 +0200
Raw View
--001a11c2b90cb970f00520dafd2a
Content-Type: text/plain; charset=UTF-8
It is a common pattern to declare a local variable of the return type of
the enclosing function, mutate it into the required result, and then return
it...
std::vector<std::pair<int,int>> build_points() {
std::vector<std::pair<int,int>> result;
while (c) result.emplace_back(g(c),h(c));
return result;
}
First, imagine we defined `auto return` as a kind of decl-specifier that
implied these two things:
1. The declared variable has the return type of the enclosing function.
2. The variable is automatically returned when the function falls off the
end:
std::vector<std::pair<int,int>> build_points() {
auto return result;
while (c) result.emplace_back(g(c),h(c));
}
Now suppose we said that this variable could be unnamed, and in such cases
the keyword return could be used as an id-expression to refer to this
return value:
std::vector<std::pair<int,int>> build_points() {
auto return;
while (c) return.emplace_back(g(c),h(c));
}
Now suppose we said that if the expression return appears in a function,
the auto return declaration is created implicitly:
std::vector<std::pair<int,int>> build_points() {
while (c) return.emplace_back(g(c),h(c));
}
Let me know if there is interest.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--001a11c2b90cb970f00520dafd2a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">It is a common pattern to declare a local variable of the =
return type of the enclosing function, mutate it into the required result, =
and then return it...<div><div><br class=3D"">=C2=A0 std::vector<std::pa=
ir<int,int>> build_points() {</div><div>=C2=A0 =C2=A0=C2=A0std::ve=
ctor<std::pair<int,int>>=C2=A0result;</div><div>=C2=A0 =C2=A0 w=
hile (c)=C2=A0result.emplace_back(g(c),h(c));</div><div>=C2=A0 =C2=A0 retur=
n=C2=A0result;<br></div><div>=C2=A0 }</div></div><div><br></div><div>First,=
imagine we defined `auto return` as a kind of decl-specifier that implied =
these two things:</div><div><br></div><div>=C2=A0 1. The declared variable =
has the return type of the enclosing function.</div><div>=C2=A0 2. The vari=
able is automatically returned when the function falls off the end:</div><d=
iv><br></div><div>=C2=A0=C2=A0std::vector<std::pair<int,int>> b=
uild_points()=C2=A0{</div><div>=C2=A0 =C2=A0 auto return=C2=A0result;</div>=
<div>=C2=A0 =C2=A0 while (c)=C2=A0result.emplace_back(g(c),h(c));</div><div=
>=C2=A0 }<br></div><div><br></div><div>Now suppose we said that this variab=
le could be unnamed, and in such cases the keyword return could be used as =
an id-expression to refer to this return value:</div><div><br></div><div><d=
iv>=C2=A0 std::vector<std::pair<int,int>> build_points()=C2=A0{=
</div><div>=C2=A0 =C2=A0 auto return;</div><div>=C2=A0 =C2=A0 while (c) ret=
urn.emplace_back(g(c),h(c));</div><div>=C2=A0 }<br></div></div><div><br></d=
iv><div>Now suppose we said that if the expression return appears in a func=
tion, the auto return declaration is created implicitly:</div><div><br></di=
v><div><div>=C2=A0 std::vector<std::pair<int,int>> build_points=
()=C2=A0{</div><div>=C2=A0 =C2=A0 while (c) return.emplace_back(g(c),h(c));=
<br></div><div>=C2=A0 }<br></div></div><div><br></div><div>Let me know if t=
here is interest.</div><div><br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a11c2b90cb970f00520dafd2a--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Mon, 28 Sep 2015 22:27:13 -0700 (PDT)
Raw View
------=_Part_5309_362540967.1443504433630
Content-Type: multipart/alternative;
boundary="----=_Part_5310_590883511.1443504433630"
------=_Part_5310_590883511.1443504433630
Content-Type: text/plain; charset=UTF-8
On Tuesday, September 29, 2015 at 12:10:18 AM UTC-4, Andrew Tomazos wrote:
>
> It is a common pattern to declare a local variable of the return type of
> the enclosing function, mutate it into the required result, and then return
> it...
>
> std::vector<std::pair<int,int>> build_points() {
> std::vector<std::pair<int,int>> result;
> while (c) result.emplace_back(g(c),h(c));
> return result;
> }
>
> First, imagine we defined `auto return` as a kind of decl-specifier that
> implied these two things:
>
> 1. The declared variable has the return type of the enclosing function.
> 2. The variable is automatically returned when the function falls off
> the end:
>
That's a combination of two entirely distinct concerns: declaring a
variable of a certain type and returning it. I don't see why we need to
take two disparate concepts and combine them into one.
We already have people tossing around the ability to get a function's
return type. That is more generally useful than what you're proposing here,
which only allows you to declare variables of that type. And really, you
only get to make one.
Also, the whole "implicit return" thing sounds like a can of worms. C++ as
a language is not required to diagnose failure to return a value from a
function with a return value. So if a user takes a quick glance at a
function, will they realize you invoked this "implicit return", or will
they assume your code is just broken?
I'm also not very convinced of your "common pattern" being that common. Or
at the very least, it's no less common than computing the value one way or
another based on conditional logic. How would such things work with
conditional returns? Would you have to structure your code to have all
conditionals coalesce at the end? Or would `return` automatically return
the value?
The ends here do not justify the means.
Now suppose we said that this variable could be unnamed, and in such cases
> the keyword return could be used as an id-expression to refer to this
> return value:
>
> std::vector<std::pair<int,int>> build_points() {
> auto return;
> while (c) return.emplace_back(g(c),h(c));
> }
>
Why would you *want* an unnamed variable? Is typing a variable name somehow
complicated? Is it an onerous burden for the user? Even in the context of
implicit return, using the variable name rather than `return` makes far
more sense.
Equally importantly, it's really confusing the issue. Are you saying that
`return.blah` is an expression or is it a return statement that evaluates
and returns an expression? Because the use of the word `return` strongly
suggests the latter, not the former.
C++ is not Perl.
Now suppose we said that if the expression return appears in a function,
> the auto return declaration is created implicitly:
>
> std::vector<std::pair<int,int>> build_points() {
> while (c) return.emplace_back(g(c),h(c));
> }
>
Now you've taken away anything that looks even *remotely* like a variable
declaration (or C++ in general). This raises a number of questions.
Where does this variable get declared? When does its constructor get
called? *How* does this variable get declared; does it get default
constructed? Is it default initialized or value initialized. What if the
type doesn't have a default constructor, or if I want to call a different
constructor? What if the default constructor throws; how would you catch
the exception?
And most importantly, why is this at all worthwhile? Seriously, is
declaring a variable and returning it really that hard?
The only way I can see this being worthwhile is for code that *would have
been* a one-liner, if not for the need to create and return a variable. And
quite frankly, that "common pattern" is not *that* common; I imagine most
code that needs to declare the return value up front also does a lot more
with it than some two-liner.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_5310_590883511.1443504433630
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Tuesday, September 29, 2015 at 12:10:18 AM UTC-4, Andrew Tomazos wrote:<=
blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bord=
er-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">It is a common=
pattern to declare a local variable of the return type of the enclosing fu=
nction, mutate it into the required result, and then return it...<div><div>=
<br>=C2=A0 std::vector<std::pair<int,int><wbr>> build_points() =
{</div><div>=C2=A0 =C2=A0=C2=A0std::vector<std::pair<int,<wbr>int>=
>=C2=A0result;</div><div>=C2=A0 =C2=A0 while (c)=C2=A0result.emplace_bac=
k(g(c),<wbr>h(c));</div><div>=C2=A0 =C2=A0 return=C2=A0result;<br></div><di=
v>=C2=A0 }</div></div><div><br></div><div>First, imagine we defined `auto r=
eturn` as a kind of decl-specifier that implied these two things:</div><div=
><br></div><div>=C2=A0 1. The declared variable has the return type of the =
enclosing function.</div><div>=C2=A0 2. The variable is automatically retur=
ned when the function falls off the end:</div></div></blockquote><div><br>T=
hat's a combination of two entirely distinct concerns: declaring a vari=
able of a certain type and returning it. I don't see why we need to tak=
e two disparate concepts and combine them into one.<br><br>We already have =
people tossing around the ability to get a function's return type. That=
is more generally useful than what you're proposing here, which only a=
llows you to declare variables of that type. And really, you only get to ma=
ke one.<br><br>Also, the whole "implicit return" thing sounds lik=
e a can of worms. C++ as a language is not required to diagnose failure to =
return a value from a function with a return value. So if a user takes a qu=
ick glance at a function, will they realize you invoked this "implicit=
return", or will they assume your code is just broken?<br><br>I'm=
also not very convinced of your "common pattern" being that comm=
on. Or at the very least, it's no less common than computing the value =
one way or another based on conditional logic. How would such things work w=
ith conditional returns? Would you have to structure your code to have all =
conditionals coalesce at the end? Or would `return` automatically return th=
e value?<br><br>The ends here do not justify the means.<br><br></div><block=
quote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-le=
ft: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div></div><div></d=
iv><div>Now suppose we said that this variable could be unnamed, and in suc=
h cases the keyword return could be used as an id-expression to refer to th=
is return value:</div><div><br></div><div><div>=C2=A0 std::vector<std::p=
air<int,int><wbr>> build_points()=C2=A0{</div><div>=C2=A0 =C2=A0 a=
uto return;</div><div>=C2=A0 =C2=A0 while (c) return.emplace_back(g(c),h(c)=
)<wbr>;</div><div>=C2=A0 }<br></div></div></div></blockquote><div><br>Why w=
ould you <i>want</i> an unnamed variable? Is typing a variable name somehow=
complicated? Is it an onerous burden for the user? Even in the context of =
implicit return, using the variable name rather than `return` makes far mor=
e sense.<br><br>Equally importantly, it's really confusing the issue. A=
re you saying that `return.blah` is an expression or is it a return stateme=
nt that evaluates and returns an expression? Because the use of the word `r=
eturn` strongly suggests the latter, not the former.<br><br>C++ is not Perl=
..<br><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=
"><div><div></div></div><div></div><div>Now suppose we said that if the exp=
ression return appears in a function, the auto return declaration is create=
d implicitly:</div><div><br></div><div><div>=C2=A0 std::vector<std::pair=
<int,int><wbr>> build_points()=C2=A0{</div><div>=C2=A0 =C2=A0 whil=
e (c) return.emplace_back(g(c),h(c))<wbr>;<br></div><div>=C2=A0 }<br></div>=
</div></div></blockquote><div><br>Now you've taken away anything that l=
ooks even <i>remotely</i> like a variable declaration (or C++ in general). =
This raises a number of questions.<br><br>Where does this variable get decl=
ared? When does its constructor get called? <i>How</i> does this variable g=
et declared; does it get default constructed? Is it default initialized or =
value initialized. What if the type doesn't have a default constructor,=
or if I want to call a different constructor? What if the default construc=
tor throws; how would you catch the exception?<br><br>And most importantly,=
why is this at all worthwhile? Seriously, is declaring a variable and retu=
rning it really that hard?<br><br>The only way I can see this being worthwh=
ile is for code that <i>would have been</i> a one-liner, if not for the nee=
d to create and return a variable. And quite frankly, that "common pat=
tern" is not <i>that</i> common; I imagine most code that needs to dec=
lare the return value up front also does a lot more with it than some two-l=
iner.<br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_5310_590883511.1443504433630--
------=_Part_5309_362540967.1443504433630--
.
Author: Andrew Tomazos <andrewtomazos@gmail.com>
Date: Tue, 29 Sep 2015 08:28:54 +0200
Raw View
--001a1130cc429c918d0520dced36
Content-Type: text/plain; charset=UTF-8
Thanks for your feedback. Questions answered below..
On Tue, Sep 29, 2015 at 7:27 AM, Nicol Bolas <jmckesson@gmail.com> wrote:
> On Tuesday, September 29, 2015 at 12:10:18 AM UTC-4, Andrew Tomazos wrote:
>>
>> It is a common pattern to declare a local variable of the return type of
>> the enclosing function, mutate it into the required result, and then return
>> it...
>>
>> std::vector<std::pair<int,int>> build_points() {
>> std::vector<std::pair<int,int>> result;
>> while (c) result.emplace_back(g(c),h(c));
>> return result;
>> }
>>
>> First, imagine we defined `auto return` as a kind of decl-specifier that
>> implied these two things:
>>
>> 1. The declared variable has the return type of the enclosing function.
>> 2. The variable is automatically returned when the function falls off
>> the end:
>>
>
> That's a combination of two entirely distinct concerns: declaring a
> variable of a certain type and returning it. I don't see why we need to
> take two disparate concepts and combine them into one.
>
> We already have people tossing around the ability to get a function's
> return type. That is more generally useful than what you're proposing here,
> which only allows you to declare variables of that type. And really, you
> only get to make one.
>
> Also, the whole "implicit return" thing sounds like a can of worms. C++ as
> a language is not required to diagnose failure to return a value from a
> function with a return value. So if a user takes a quick glance at a
> function, will they realize you invoked this "implicit return", or will
> they assume your code is just broken?
>
While forgetting to return from a value-returning function is technically
UB, there is a defacto standard warning that every implementation has to
diagnose such cases.
I'm also not very convinced of your "common pattern" being that common. Or
> at the very least, it's no less common than computing the value one way or
> another based on conditional logic. How would such things work with
> conditional returns? Would you have to structure your code to have all
> conditionals coalesce at the end? Or would `return` automatically return
> the value?
>
I'm not sure what a conditional return is. If you are returning one of
multiple different expressions (or anything other than an id-expression to
a single return object) then I think you would do it the normal way. The
proposed feature is purely for the pattern where you construct the result
object at the start of the function and then mutate it throughout the
function.
The ends here do not justify the means.
>
> Now suppose we said that this variable could be unnamed, and in such cases
>> the keyword return could be used as an id-expression to refer to this
>> return value:
>>
>> std::vector<std::pair<int,int>> build_points() {
>> auto return;
>> while (c) return.emplace_back(g(c),h(c));
>> }
>>
>
> Why would you *want* an unnamed variable? Is typing a variable name
> somehow complicated? Is it an onerous burden for the user? Even in the
> context of implicit return, using the variable name rather than `return`
> makes far more sense.
>
There are a number of places in the language where an unnamed entity is
defined, used or deduced. I guess the motivation is the same as for those.
Equally importantly, it's really confusing the issue. Are you saying that
> `return.blah` is an expression or is it a return statement that evaluates
> and returns an expression? Because the use of the word `return` strongly
> suggests the latter, not the former.
>
If you're saying that there is some visual ambiguity, then that may be so.
As for parsing ambiguity, return.blah is not one. return.blah is
unambiguously an expression. The LHS is the id-expression refering to the
auto return object.
There are some parsing ambiguities like:
return(x);
Is this an expression statement calling operator() of the return object, or
a return statement returning x. These ambiguities would have to be
resolved as part of the proposal (most likely "if it can be a return
statement, it is a return statement").
C++ is not Perl.
>
> Now suppose we said that if the expression return appears in a function,
>> the auto return declaration is created implicitly:
>>
>> std::vector<std::pair<int,int>> build_points() {
>> while (c) return.emplace_back(g(c),h(c));
>> }
>>
>
> Now you've taken away anything that looks even *remotely* like a variable
> declaration (or C++ in general). This raises a number of questions.
>
> Where does this variable get declared?
>
An auto return declaration statement is inserted implicitly at the start of
the function definition (if a return id-expression appears in the function
definition).
> When does its constructor get called?
>
At the start of the function.
> *How* does this variable get declared; does it get default constructed?
>
Yes.
> Is it default initialized or value initialized.
>
It is as-if it was declared without an initializer:
T f() {
T x; // <-- like this
I can't remember which this implies off the top of my head.
What if the type doesn't have a default constructor,
>
Ill-formed.
> or if I want to call a different constructor?
>
With the third implicit form, you can't. With the second unnamed form
maybe we could say:
auto return(1,2,3);
is ok. That is, it can be trailed with an initializer.
> What if the default constructor throws; how would you catch the exception?
>
I can't remember if this works:
void f() {
return++;
} catch (...) {
}
But if it does, it would catch an exception thrown from the return
constructor.
Otherwise, you can't catch it. (I'm not sure what you plan to return if a
default constructed return value of your function throws.)
And most importantly, why is this at all worthwhile? Seriously, is
> declaring a variable and returning it really that hard?
>
The motivation is mainly providing a terser syntax for an, in my opinion,
common pattern (as an example, a similar motivation to, although much
smaller than, lambdas). If you don't think the pattern is common I can see
how it would follow that you think it isn't worthwhile.
The only way I can see this being worthwhile is for code that *would have
> been* a one-liner, if not for the need to create and return a variable.
> And quite frankly, that "common pattern" is not *that* common; I imagine
> most code that needs to declare the return value up front also does a lot
> more with it than some two-liner.
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--001a1130cc429c918d0520dced36
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Thanks for your feedback.=C2=A0 Questions answered below..=
<br><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Tue, Sep 2=
9, 2015 at 7:27 AM, Nicol Bolas <span dir=3D"ltr"><<a href=3D"mailto:jmc=
kesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>></span> wrot=
e:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><span class=3D"">On Tuesday, September=
29, 2015 at 12:10:18 AM UTC-4, Andrew Tomazos wrote:<blockquote class=3D"g=
mail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;=
padding-left:1ex"><div dir=3D"ltr">It is a common pattern to declare a loca=
l variable of the return type of the enclosing function, mutate it into the=
required result, and then return it...<div><div><br>=C2=A0 std::vector<=
std::pair<int,int>> build_points() {</div><div>=C2=A0 =C2=A0=C2=A0=
std::vector<std::pair<int,int>>=C2=A0result;</div><div>=C2=A0 =
=C2=A0 while (c)=C2=A0result.emplace_back(g(c),h(c));</div><div>=C2=A0 =C2=
=A0 return=C2=A0result;<br></div><div>=C2=A0 }</div></div><div><br></div><d=
iv>First, imagine we defined `auto return` as a kind of decl-specifier that=
implied these two things:</div><div><br></div><div>=C2=A0 1. The declared =
variable has the return type of the enclosing function.</div><div>=C2=A0 2.=
The variable is automatically returned when the function falls off the end=
:</div></div></blockquote></span><div><br>That's a combination of two e=
ntirely distinct concerns: declaring a variable of a certain type and retur=
ning it. I don't see why we need to take two disparate concepts and com=
bine them into one.<br><br>We already have people tossing around the abilit=
y to get a function's return type. That is more generally useful than w=
hat you're proposing here, which only allows you to declare variables o=
f that type. And really, you only get to make one.<br><br>Also, the whole &=
quot;implicit return" thing sounds like a can of worms. C++ as a langu=
age is not required to diagnose failure to return a value from a function w=
ith a return value. So if a user takes a quick glance at a function, will t=
hey realize you invoked this "implicit return", or will they assu=
me your code is just broken?<br></div></blockquote><div>=C2=A0</div><div>Wh=
ile forgetting to return from a value-returning function is technically UB,=
there is a defacto standard warning that every implementation has to diagn=
ose such cases.</div><div><br></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>I&#=
39;m also not very convinced of your "common pattern" being that =
common. Or at the very least, it's no less common than computing the va=
lue one way or another based on conditional logic. How would such things wo=
rk with conditional returns? Would you have to structure your code to have =
all conditionals coalesce at the end? Or would `return` automatically retur=
n the value?<br></div></blockquote><div>=C2=A0</div><div>I'm not sure w=
hat a conditional return is.=C2=A0 If you are returning one of multiple dif=
ferent expressions (or anything other than an id-expression to a single ret=
urn object) then I think you would do it the normal way.=C2=A0 The proposed=
feature is purely for the pattern where you construct the result object at=
the start of the function and then mutate it throughout the function.</div=
><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8e=
x;border-left:1px #ccc solid;padding-left:1ex"><div>The ends here do not ju=
stify the means.<br><br></div><span class=3D""><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"><div></div><div></div><div>Now suppose we said=
that this variable could be unnamed, and in such cases the keyword return =
could be used as an id-expression to refer to this return value:</div><div>=
<br></div><div><div>=C2=A0 std::vector<std::pair<int,int>> buil=
d_points()=C2=A0{</div><div>=C2=A0 =C2=A0 auto return;</div><div>=C2=A0 =C2=
=A0 while (c) return.emplace_back(g(c),h(c));</div><div>=C2=A0 }<br></div><=
/div></div></blockquote></span><div><br>Why would you <i>want</i> an unname=
d variable? Is typing a variable name somehow complicated? Is it an onerous=
burden for the user? Even in the context of implicit return, using the var=
iable name rather than `return` makes far more sense.<br></div></blockquote=
><div>=C2=A0</div><div>There are a number of places in the language where a=
n unnamed entity is defined, used or deduced.=C2=A0 I guess the motivation =
is the same as for those.</div><div><br></div><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex=
"><div>Equally importantly, it's really confusing the issue. Are you sa=
ying that `return.blah` is an expression or is it a return statement that e=
valuates and returns an expression? Because the use of the word `return` st=
rongly suggests the latter, not the former.<br></div></blockquote><div>=C2=
=A0</div><div>If you're saying that there is some visual ambiguity, the=
n that may be so.</div><div><br></div><div>As for parsing ambiguity, return=
..blah is not one. return.blah is unambiguously an expression.=C2=A0 The LHS=
is the id-expression refering to the auto return object.</div><div><br></d=
iv><div>There are some parsing ambiguities like:</div><div><br></div><div>=
=C2=A0 =C2=A0return(x);</div><div><br></div><div>Is this an expression stat=
ement calling operator() of the return object, or a return statement return=
ing x.=C2=A0 These ambiguities would have to be resolved as part of the pro=
posal (most likely "if it can be a return statement, it is a return st=
atement").</div><div><br></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>C++=
is not Perl.<br><br></div><span class=3D""><blockquote class=3D"gmail_quot=
e" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-l=
eft:1ex"><div dir=3D"ltr"><div><div></div></div><div></div><div>Now suppose=
we said that if the expression return appears in a function, the auto retu=
rn declaration is created implicitly:</div><div><br></div><div><div>=C2=A0 =
std::vector<std::pair<int,int>> build_points()=C2=A0{</div><div=
>=C2=A0 =C2=A0 while (c) return.emplace_back(g(c),h(c));<br></div><div>=C2=
=A0 }<br></div></div></div></blockquote></span><div><br>Now you've take=
n away anything that looks even <i>remotely</i> like a variable declaration=
(or C++ in general). This raises a number of questions.<br><br>Where does =
this variable get declared? </div></blockquote><div><br></div><div>An auto =
return declaration statement is inserted implicitly at the start of the fun=
ction definition (if a return id-expression appears in the function definit=
ion).=C2=A0</div><div>=C2=A0=C2=A0</div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div=
>When does its constructor get called?</div></blockquote><div><br></div><di=
v>At the start of the function.</div><div>=C2=A0</div><blockquote class=3D"=
gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-=
left:1ex"><div> <i>How</i> does this variable get declared; does it get def=
ault constructed?</div></blockquote><div><br></div><div>Yes.</div><div>=C2=
=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
r-left:1px #ccc solid;padding-left:1ex"><div>Is it default initialized or v=
alue initialized.</div></blockquote><div><br></div><div>It is as-if it was =
declared without an initializer:</div><div><br></div><div>=C2=A0 T f() {</d=
iv><div>=C2=A0 =C2=A0 T x; =C2=A0// <-- like this</div><div>=C2=A0</div>=
<div>I can't remember which this implies off the top of my head.</div><=
div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex"><div> What if the type doesn&#=
39;t have a default constructor,</div></blockquote><div><br></div><div>Ill-=
formed.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div> or if I =
want to call a different constructor? </div></blockquote><div><br></div><di=
v>With the third implicit form, you can't.=C2=A0 With the second unname=
d form maybe we could say:</div><div><br></div><div>=C2=A0 =C2=A0auto retur=
n(1,2,3);</div><div><br></div><div>is ok.=C2=A0 That is, it can be trailed =
with an initializer.</div><div>=C2=A0<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>What if the default constructor throws; how would you catch the exc=
eption?<br></div></blockquote><div><br></div><div>I can't remember if t=
his works:</div><div><br></div><div>=C2=A0 =C2=A0 void f() {</div><div>=C2=
=A0 =C2=A0 =C2=A0 return++;</div><div>=C2=A0 =C2=A0 } catch (...) {</div><d=
iv>=C2=A0 =C2=A0 }</div><div><br></div><div>But if it does, it would catch =
an exception thrown from the return constructor.</div><div><br></div><div>O=
therwise, you can't catch it. =C2=A0(I'm not sure what you plan to =
return if a default constructed return value of your function throws.)</div=
><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8e=
x;border-left:1px #ccc solid;padding-left:1ex"><div>And most importantly, w=
hy is this at all worthwhile? Seriously, is declaring a variable and return=
ing it really that hard?<br></div></blockquote><div>=C2=A0</div><div>The mo=
tivation is mainly providing a terser syntax for an, in my opinion, common =
pattern (as an example, a similar motivation to, although much smaller than=
, lambdas).=C2=A0 If you don't think the pattern is common I can see ho=
w it would follow that you think it isn't worthwhile.</div><div><br></d=
iv><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left=
:1px #ccc solid;padding-left:1ex"><div>The only way I can see this being wo=
rthwhile is for code that <i>would have been</i> a one-liner, if not for th=
e need to create and return a variable. And quite frankly, that "commo=
n pattern" is not <i>that</i> common; I imagine most code that needs t=
o declare the return value up front also does a lot more with it than some =
two-liner.<span class=3D"HOEnZb"><font color=3D"#888888"><br></font></span>=
</div><span class=3D"HOEnZb"><font color=3D"#888888">
<p></p>
-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</font></span></blockquote></div><br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a1130cc429c918d0520dced36--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Tue, 29 Sep 2015 07:09:02 -0700 (PDT)
Raw View
------=_Part_474_163516446.1443535743058
Content-Type: multipart/alternative;
boundary="----=_Part_475_1419177943.1443535743058"
------=_Part_475_1419177943.1443535743058
Content-Type: text/plain; charset=UTF-8
On Tuesday, September 29, 2015 at 2:28:58 AM UTC-4, Andrew Tomazos wrote:
>
> Thanks for your feedback. Questions answered below..
>
> On Tuesday, September 29, 2015 at 12:10:18 AM UTC-4, Andrew Tomazos wrote:On
>> Tue, Sep 29, 2015 at 7:27 AM, Nicol Bolas <jmck...@gmail.com
>> <javascript:>> wrote:
>>
> Now suppose we said that this variable could be unnamed, and in such cases
>>> the keyword return could be used as an id-expression to refer to this
>>> return value:
>>>
>>> std::vector<std::pair<int,int>> build_points() {
>>> auto return;
>>> while (c) return.emplace_back(g(c),h(c));
>>> }
>>>
>>
>> Why would you *want* an unnamed variable? Is typing a variable name
>> somehow complicated? Is it an onerous burden for the user? Even in the
>> context of implicit return, using the variable name rather than `return`
>> makes far more sense.
>>
>
> There are a number of places in the language where an unnamed entity is
> defined, used or deduced. I guess the motivation is the same as for those.
>
For values, yes this is true. However, those values are always (as far as I
recall) *temporaries* that do not outlive the line in which they are
generated. You're talking about deliberately declaring an unnamed *variable*
..
That's very new for C++.
Equally importantly, it's really confusing the issue. Are you saying that
>> `return.blah` is an expression or is it a return statement that evaluates
>> and returns an expression? Because the use of the word `return` strongly
>> suggests the latter, not the former.
>>
>
> If you're saying that there is some visual ambiguity, then that may be so.
>
Yes, I was talking about user confusion. But parsing ambiguities don't help
your case.
As for parsing ambiguity, return.blah is not one. return.blah is
> unambiguously an expression. The LHS is the id-expression refering to the
> auto return object.
>
Let's say we use your suggested parsing rule of "if it can be a return
statement, it is a return statement".
So let's consider `return 5;`. That's a return statement. But did you *mean*
for it to be a return statement? Or did you mean `return = 5` and you
accidentally typed the wrong thing? If your return type is implicitly
convertible from an integer, the compiler will accept either one. And the
two mean very different things, with `return 5` immediately halting
execution.
That is a very nasty, completely *silent* breakage. That's bad.
FYI: rules like the one you suggest gave us the Most Vexing Parse
<https://en.wikipedia.org/wiki/Most_vexing_parse>. We should not
deliberately add features like that again.
If you had just introduced an actual name, that wouldn't be necessary.
There are some parsing ambiguities like:
>
> return(x);
>
> Is this an expression statement calling operator() of the return object,
> or a return statement returning x. These ambiguities would have to be
> resolved as part of the proposal (most likely "if it can be a return
> statement, it is a return statement").
>
Which would limit the ways in which you can use this implicit variable. You
can't even call operator() on it without shenanigans (like `(return)()` or
whatever). Though at least that may well be a noisy breakage.
> Is it default initialized or value initialized.
>>
>
> It is as-if it was declared without an initializer:
>
> T f() {
> T x; // <-- like this
>
> I can't remember which this implies off the top of my head.
>
That's default initialization
<http://en.cppreference.com/w/cpp/language/default_initialization>, so for
many types, they go uninitialized. That's generally considered bad these
days. Or at least, it's not good for it to be the default case.
What if the type doesn't have a default constructor,
>>
>
> Ill-formed.
>
>
or if I want to call a different constructor?
>>
>
> With the third implicit form, you can't.
>
Doesn't this restriction significantly limit how much users can use this
"common pattern"? Even if only 30% of uses of this pattern used a
non-default constructor, that's still almost 1/3rd of potential users who
can't use this feature.
So ultimately, all they save is a return at the bottom of the function.
Again, is that *one line* worth the syntactic burden?
> What if the default constructor throws; how would you catch the exception?
>>
>
> I can't remember if this works:
>
> void f() {
> return++;
> } catch (...) {
> }
>
> But if it does, it would catch an exception thrown from the return
> constructor.
>
Well, that particular syntax doesn't work. But it is possible to create function-level
try/catch blocks
<http://en.cppreference.com/w/cpp/language/function-try-block>.
But really, you shouldn't encourage that.
> And most importantly, why is this at all worthwhile? Seriously, is
>> declaring a variable and returning it really that hard?
>>
>
> The motivation is mainly providing a terser syntax for an, in my opinion,
> common pattern (as an example, a similar motivation to, although much
> smaller than, lambdas).
>
You're saving 2 lines of code. In a function that's just 10 lines long
(including declaration and {}s), that's only a 20% reduction in code size.
And the shorter said code is, the *less* likely it is that you will need to
use this pattern.
And you can only save two lines of code if you use the
default-construct-followed-by-initialization pattern. If you need to use an
actual constructor, you save... one line of code. Only 10% in a 10 line
function.
If a full quarter of your functions use the first pattern (and I rather
doubt it's even that common), you will save maybe 5% of actual lines of
text.
So even if this pattern were common, you ultimately don't save much. And
the downsides of the feature make it harder to reason about code (thanks
to `return` ambiguities), introduce unnamed variables, and make functions
behave in a way that is very new (automatically returning values).
Lambdas save you tons of very difficult-to-write code, especially if they
capture values. Thus far, your feature saves you 2 lines of
trivial-to-write code.
So I'm failing to see the cost/benefit here.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_475_1419177943.1443535743058
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Tuesday, September 29, 2015 at 2:28:58 AM UTC-4, Andrew Tomazos wrote:<b=
lockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;borde=
r-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">Thanks for your=
feedback.=C2=A0 Questions answered below..<br><div><br><div class=3D"gmail=
_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border=
-left:1px #ccc solid;padding-left:1ex"><span>On Tuesday, September 29, 2015=
at 12:10:18 AM UTC-4, Andrew Tomazos wrote:</span>On Tue, Sep 29, 2015 at =
7:27 AM, Nicol Bolas <span dir=3D"ltr"><<a href=3D"javascript:" target=
=3D"_blank" gdf-obfuscated-mailto=3D"yTE7HNbjCQAJ" rel=3D"nofollow" onmouse=
down=3D"this.href=3D'javascript:';return true;" onclick=3D"this.hre=
f=3D'javascript:';return true;">jmck...@gmail.com</a>></span> wr=
ote:<br></blockquote><div></div><blockquote class=3D"gmail_quote" style=3D"=
margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div></div><=
span><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></div><d=
iv></div><div>Now suppose we said that this variable could be unnamed, and =
in such cases the keyword return could be used as an id-expression to refer=
to this return value:</div><div><br></div><div><div>=C2=A0 std::vector<=
std::pair<int,int><wbr>> build_points()=C2=A0{</div><div>=C2=A0 =
=C2=A0 auto return;</div><div>=C2=A0 =C2=A0 while (c) return.emplace_back(g=
(c),h(c))<wbr>;</div><div>=C2=A0 }<br></div></div></div></blockquote></span=
><div><br>Why would you <i>want</i> an unnamed variable? Is typing a variab=
le name somehow complicated? Is it an onerous burden for the user? Even in =
the context of implicit return, using the variable name rather than `return=
` makes far more sense.<br></div></blockquote><div>=C2=A0</div><div>There a=
re a number of places in the language where an unnamed entity is defined, u=
sed or deduced.=C2=A0 I guess the motivation is the same as for those.</div=
></div></div></div></blockquote><div><br>For values, yes this is true. Howe=
ver, those values are always (as far as I recall) <i>temporaries</i> that d=
o not outlive the line in which they are generated. You're talking abou=
t deliberately declaring an unnamed <i>variable</i>.<br><br>That's very=
new for C++.<br><br></div><blockquote class=3D"gmail_quote" style=3D"margi=
n: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><di=
v dir=3D"ltr"><div><div class=3D"gmail_quote"><div></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div>Equally importantly, it's really confusing the issue=
.. Are you saying that `return.blah` is an expression or is it a return stat=
ement that evaluates and returns an expression? Because the use of the word=
`return` strongly suggests the latter, not the former.<br></div></blockquo=
te><div>=C2=A0</div><div>If you're saying that there is some visual amb=
iguity, then that may be so.</div></div></div></div></blockquote><div><br>Y=
es, I was talking about user confusion. But parsing ambiguities don't h=
elp your case.<br><br></div><blockquote class=3D"gmail_quote" style=3D"marg=
in: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><d=
iv dir=3D"ltr"><div><div class=3D"gmail_quote"><div></div><div>As for parsi=
ng ambiguity, return.blah is not one. return.blah is unambiguously an expre=
ssion.=C2=A0 The LHS is the id-expression refering to the auto return objec=
t.</div></div></div></div></blockquote><div><br>Let's say we use your s=
uggested parsing rule of "if it can be a return statement, it is a ret=
urn statement".<br><br>So let's consider `return 5;`. That's a=
return statement. But did you <i>mean</i> for it to be a return statement?=
Or did you mean `return =3D 5` and you accidentally typed the wrong thing?=
If your return type is implicitly convertible from an integer, the compile=
r will accept either one. And the two mean very different things, with `ret=
urn 5` immediately halting execution.<br><br>That is a very nasty, complete=
ly <i>silent</i> breakage. That's bad.<br><br>FYI: rules like the one y=
ou suggest gave us the <a href=3D"https://en.wikipedia.org/wiki/Most_vexing=
_parse">Most Vexing Parse</a>. We should not deliberately add features like=
that again.<br><br>If you had just introduced an actual name, that wouldn&=
#39;t be necessary.<br><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"><div><div class=3D"gmail_quote"><div></div><div>There a=
re some parsing ambiguities like:</div><div><br></div><div>=C2=A0 =C2=A0ret=
urn(x);</div><div><br></div><div>Is this an expression statement calling op=
erator() of the return object, or a return statement returning x.=C2=A0 The=
se ambiguities would have to be resolved as part of the proposal (most like=
ly "if it can be a return statement, it is a return statement").<=
/div></div></div></div></blockquote><div><br>Which would limit the ways in =
which you can use this implicit variable. You can't even call operator(=
) on it without shenanigans (like `(return)()` or whatever). Though at leas=
t that may well be a noisy breakage.<br>=C2=A0</div><blockquote class=3D"gm=
ail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc soli=
d;padding-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><div=
></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-=
left:1px #ccc solid;padding-left:1ex"><div>Is it default initialized or val=
ue initialized.</div></blockquote><div><br></div><div>It is as-if it was de=
clared without an initializer:</div><div><br></div><div>=C2=A0 T f() {</div=
><div>=C2=A0 =C2=A0 T x; =C2=A0// <-- like this</div><div>=C2=A0</div><d=
iv>I can't remember which this implies off the top of my head.</div></d=
iv></div></div></blockquote><div><br>That's <a href=3D"http://en.cppref=
erence.com/w/cpp/language/default_initialization">default initialization</a=
>, so for many types, they go uninitialized. That's generally considere=
d bad these days. Or at least, it's not good for it to be the default c=
ase.<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"=
ltr"><div><div class=3D"gmail_quote"><div></div><blockquote class=3D"gmail_=
quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1=
ex"><div> What if the type doesn't have a default constructor,</div></b=
lockquote><div><br></div><div>Ill-formed.</div></div></div></div></blockquo=
te><blockquote style=3D"margin: 0px 0px 0px 0.8ex; border-left: 1px solid r=
gb(204, 204, 204); padding-left: 1ex;" class=3D"gmail_quote"><div>=C2=A0</d=
iv></blockquote><div></div><blockquote class=3D"gmail_quote" style=3D"margi=
n: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><di=
v dir=3D"ltr"><div><div class=3D"gmail_quote"><div></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div> or if I want to call a different constructor? </div></b=
lockquote><div><br></div><div>With the third implicit form, you can't.<=
/div></div></div></div></blockquote><div><br>Doesn't this restriction s=
ignificantly limit how much users can use this "common pattern"? =
Even if only 30% of uses of this pattern used a non-default constructor, th=
at's still almost 1/3rd of potential users who can't use this featu=
re.<br><br>So ultimately, all they save is a return at the bottom of the fu=
nction. Again, is that <i>one line</i> worth the syntactic burden?<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"><div=
><div class=3D"gmail_quote"><div></div><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>=
What if the default constructor throws; how would you catch the exception?<=
br></div></blockquote><div><br></div><div>I can't remember if this work=
s:</div><div><br></div><div>=C2=A0 =C2=A0 void f() {</div><div>=C2=A0 =C2=
=A0 =C2=A0 return++;</div><div>=C2=A0 =C2=A0 } catch (...) {</div><div>=C2=
=A0 =C2=A0 }</div><div><br></div><div>But if it does, it would catch an exc=
eption thrown from the return constructor.</div></div></div></div></blockqu=
ote><div><br>Well, that particular syntax doesn't work. But it is possi=
ble to create <a href=3D"http://en.cppreference.com/w/cpp/language/function=
-try-block">function-level try/catch blocks</a>.<br><br>But really, you sho=
uldn't encourage that.<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"><div><div class=3D"gmail_quote"><div></div><di=
v></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border=
-left:1px #ccc solid;padding-left:1ex"><div>And most importantly, why is th=
is at all worthwhile? Seriously, is declaring a variable and returning it r=
eally that hard?<br></div></blockquote><div>=C2=A0</div><div>The motivation=
is mainly providing a terser syntax for an, in my opinion, common pattern =
(as an example, a similar motivation to, although much smaller than, lambda=
s).</div></div></div></div></blockquote><div><br>You're saving 2 lines =
of code. In a function that's just 10 lines long (including declaration=
and {}s), that's only a 20% reduction in code size. And the shorter sa=
id code is, the <i>less</i> likely it is that you will need to use this pat=
tern.<br><br>And you can only save two lines of code if you use the default=
-construct-followed-by-initialization pattern. If you need to use an actual=
constructor, you save... one line of code. Only 10% in a 10 line function.=
<br><br>If a full quarter of your functions use the first pattern (and I ra=
ther doubt it's even that common), you will save maybe 5% of actual lin=
es of text.<br><br>So even if this pattern were common, you ultimately don&=
#39;t save much. And the downsides of the feature make=C2=A0 it harder to r=
eason about code (thanks to `return` ambiguities), introduce unnamed variab=
les, and make functions behave in a way that is very new (automatically ret=
urning values).<br><br>Lambdas save you tons of very difficult-to-write cod=
e, especially if they capture values. Thus far, your feature saves you 2 li=
nes of trivial-to-write code.<br><br>So I'm failing to see the cost/ben=
efit here.<br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_475_1419177943.1443535743058--
------=_Part_474_163516446.1443535743058--
.
Author: little3lue <little3lue@gmail.com>
Date: Tue, 29 Sep 2015 20:08:40 +0000
Raw View
--94eb2c032818e9255d0520e8613a
Content-Type: text/plain; charset=UTF-8
Some languages allow creating a named variable for the return type, as part
of the function definition.
E.g. strawman:
// foo.h
Foo getFoo();
// foo.cpp
(Foo foo) getFoo() {
// foo is initialized and "automatically returned" unless another value
is explicitly returned
foo.fizzle();
}
// Or maybe:
auto getFoo -> Foo foo {
}
-Michal
On Tue, Sep 29, 2015 at 10:09 AM Nicol Bolas <jmckesson@gmail.com> wrote:
> On Tuesday, September 29, 2015 at 2:28:58 AM UTC-4, Andrew Tomazos wrote:
>>
>> Thanks for your feedback. Questions answered below..
>>
>
>> On Tuesday, September 29, 2015 at 12:10:18 AM UTC-4, Andrew Tomazos wrote:On
>>> Tue, Sep 29, 2015 at 7:27 AM, Nicol Bolas <jmck...@gmail.com> wrote:
>>>
>> Now suppose we said that this variable could be unnamed, and in such
>>>> cases the keyword return could be used as an id-expression to refer to this
>>>> return value:
>>>>
>>>> std::vector<std::pair<int,int>> build_points() {
>>>> auto return;
>>>> while (c) return.emplace_back(g(c),h(c));
>>>> }
>>>>
>>>
>>> Why would you *want* an unnamed variable? Is typing a variable name
>>> somehow complicated? Is it an onerous burden for the user? Even in the
>>> context of implicit return, using the variable name rather than `return`
>>> makes far more sense.
>>>
>>
>> There are a number of places in the language where an unnamed entity is
>> defined, used or deduced. I guess the motivation is the same as for those.
>>
>
> For values, yes this is true. However, those values are always (as far as
> I recall) *temporaries* that do not outlive the line in which they are
> generated. You're talking about deliberately declaring an unnamed
> *variable*.
>
> That's very new for C++.
>
> Equally importantly, it's really confusing the issue. Are you saying that
>>> `return.blah` is an expression or is it a return statement that evaluates
>>> and returns an expression? Because the use of the word `return` strongly
>>> suggests the latter, not the former.
>>>
>>
>> If you're saying that there is some visual ambiguity, then that may be so.
>>
>
> Yes, I was talking about user confusion. But parsing ambiguities don't
> help your case.
>
> As for parsing ambiguity, return.blah is not one. return.blah is
>> unambiguously an expression. The LHS is the id-expression refering to the
>> auto return object.
>>
>
> Let's say we use your suggested parsing rule of "if it can be a return
> statement, it is a return statement".
>
> So let's consider `return 5;`. That's a return statement. But did you
> *mean* for it to be a return statement? Or did you mean `return = 5` and
> you accidentally typed the wrong thing? If your return type is implicitly
> convertible from an integer, the compiler will accept either one. And the
> two mean very different things, with `return 5` immediately halting
> execution.
>
> That is a very nasty, completely *silent* breakage. That's bad.
>
> FYI: rules like the one you suggest gave us the Most Vexing Parse
> <https://en.wikipedia.org/wiki/Most_vexing_parse>. We should not
> deliberately add features like that again.
>
> If you had just introduced an actual name, that wouldn't be necessary.
>
> There are some parsing ambiguities like:
>>
>> return(x);
>>
>> Is this an expression statement calling operator() of the return object,
>> or a return statement returning x. These ambiguities would have to be
>> resolved as part of the proposal (most likely "if it can be a return
>> statement, it is a return statement").
>>
>
> Which would limit the ways in which you can use this implicit variable.
> You can't even call operator() on it without shenanigans (like `(return)()`
> or whatever). Though at least that may well be a noisy breakage.
>
>
>> Is it default initialized or value initialized.
>>>
>>
>> It is as-if it was declared without an initializer:
>>
>> T f() {
>> T x; // <-- like this
>>
>> I can't remember which this implies off the top of my head.
>>
>
> That's default initialization
> <http://en.cppreference.com/w/cpp/language/default_initialization>, so
> for many types, they go uninitialized. That's generally considered bad
> these days. Or at least, it's not good for it to be the default case.
>
> What if the type doesn't have a default constructor,
>>>
>>
>> Ill-formed.
>>
>
>>
> or if I want to call a different constructor?
>>>
>>
>> With the third implicit form, you can't.
>>
>
> Doesn't this restriction significantly limit how much users can use this
> "common pattern"? Even if only 30% of uses of this pattern used a
> non-default constructor, that's still almost 1/3rd of potential users who
> can't use this feature.
>
> So ultimately, all they save is a return at the bottom of the function.
> Again, is that *one line* worth the syntactic burden?
>
>
>> What if the default constructor throws; how would you catch the exception?
>>>
>>
>> I can't remember if this works:
>>
>> void f() {
>> return++;
>> } catch (...) {
>> }
>>
>> But if it does, it would catch an exception thrown from the return
>> constructor.
>>
>
> Well, that particular syntax doesn't work. But it is possible to create function-level
> try/catch blocks
> <http://en.cppreference.com/w/cpp/language/function-try-block>.
>
> But really, you shouldn't encourage that.
>
>
>> And most importantly, why is this at all worthwhile? Seriously, is
>>> declaring a variable and returning it really that hard?
>>>
>>
>> The motivation is mainly providing a terser syntax for an, in my opinion,
>> common pattern (as an example, a similar motivation to, although much
>> smaller than, lambdas).
>>
>
> You're saving 2 lines of code. In a function that's just 10 lines long
> (including declaration and {}s), that's only a 20% reduction in code size.
> And the shorter said code is, the *less* likely it is that you will need
> to use this pattern.
>
> And you can only save two lines of code if you use the
> default-construct-followed-by-initialization pattern. If you need to use an
> actual constructor, you save... one line of code. Only 10% in a 10 line
> function.
>
> If a full quarter of your functions use the first pattern (and I rather
> doubt it's even that common), you will save maybe 5% of actual lines of
> text.
>
> So even if this pattern were common, you ultimately don't save much. And
> the downsides of the feature make it harder to reason about code (thanks
> to `return` ambiguities), introduce unnamed variables, and make functions
> behave in a way that is very new (automatically returning values).
>
> Lambdas save you tons of very difficult-to-write code, especially if they
> capture values. Thus far, your feature saves you 2 lines of
> trivial-to-write code.
>
> So I'm failing to see the cost/benefit here.
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--94eb2c032818e9255d0520e8613a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Some languages allow creating a named variable for the ret=
urn type, as part of the function definition.<div><br></div><div>E.g. straw=
man:</div><div><br></div><div>// foo.h</div><div>Foo getFoo();</div><div><b=
r></div><div>// foo.cpp</div><div>(Foo foo) getFoo() {</div><div>=C2=A0 // =
foo is initialized and "automatically returned" unless another va=
lue is explicitly returned</div><div>=C2=A0 foo.fizzle();</div><div>}</div>=
<div><br></div><div>// Or maybe:</div><div>auto getFoo -> Foo foo {</div=
><div>}</div><div><br></div><div>-Michal</div></div><br><div class=3D"gmail=
_quote"><div dir=3D"ltr">On Tue, Sep 29, 2015 at 10:09 AM Nicol Bolas <<=
a href=3D"mailto:jmckesson@gmail.com">jmckesson@gmail.com</a>> wrote:<br=
></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-=
left:1px #ccc solid;padding-left:1ex">On Tuesday, September 29, 2015 at 2:2=
8:58 AM UTC-4, Andrew Tomazos 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">Thanks for your feedback.=C2=A0 Questions answered below.=
..<br></div></blockquote><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><br><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote"=
style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><s=
pan>On Tuesday, September 29, 2015 at 12:10:18 AM UTC-4, Andrew Tomazos wro=
te:</span>On Tue, Sep 29, 2015 at 7:27 AM, Nicol Bolas <span dir=3D"ltr">&l=
t;<a rel=3D"nofollow">jmck...@gmail.com</a>></span> wrote:<br></blockquo=
te><div></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex"><div></div><span><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #c=
cc solid;padding-left:1ex"><div dir=3D"ltr"><div></div><div></div><div>Now =
suppose we said that this variable could be unnamed, and in such cases the =
keyword return could be used as an id-expression to refer to this return va=
lue:</div><div><br></div><div><div>=C2=A0 std::vector<std::pair<int,i=
nt>> build_points()=C2=A0{</div><div>=C2=A0 =C2=A0 auto return;</div>=
<div>=C2=A0 =C2=A0 while (c) return.emplace_back(g(c),h(c));</div><div>=C2=
=A0 }<br></div></div></div></blockquote></span><div><br>Why would you <i>wa=
nt</i> an unnamed variable? Is typing a variable name somehow complicated? =
Is it an onerous burden for the user? Even in the context of implicit retur=
n, using the variable name rather than `return` makes far more sense.<br></=
div></blockquote><div>=C2=A0</div><div>There are a number of places in the =
language where an unnamed entity is defined, used or deduced.=C2=A0 I guess=
the motivation is the same as for those.</div></div></div></div></blockquo=
te><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"></div></blockqu=
ote><div><br>For values, yes this is true. However, those values are always=
(as far as I recall) <i>temporaries</i> that do not outlive the line in wh=
ich they are generated. You're talking about deliberately declaring an =
unnamed <i>variable</i>.<br><br>That's very new for C++.<br><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"><div><div class=3D"=
gmail_quote"><div></div><blockquote class=3D"gmail_quote" style=3D"margin:0=
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>Equally importa=
ntly, it's really confusing the issue. Are you saying that `return.blah=
` is an expression or is it a return statement that evaluates and returns a=
n expression? Because the use of the word `return` strongly suggests the la=
tter, not the former.<br></div></blockquote><div>=C2=A0</div><div>If you=
9;re saying that there is some visual ambiguity, then that may be so.</div>=
</div></div></div></blockquote><div><br>Yes, I was talking about user confu=
sion. But parsing ambiguities don't help your case.<br><br></div><block=
quote 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><div class=3D"gmail=
_quote"><div></div><div>As for parsing ambiguity, return.blah is not one. r=
eturn.blah is unambiguously an expression.=C2=A0 The LHS is the id-expressi=
on refering to the auto return object.</div></div></div></div></blockquote>=
<div><br>Let's say we use your suggested parsing rule of "if it ca=
n be a return statement, it is a return statement".<br><br>So let'=
s consider `return 5;`. That's a return statement. But did you <i>mean<=
/i> for it to be a return statement? Or did you mean `return =3D 5` and you=
accidentally typed the wrong thing? If your return type is implicitly conv=
ertible from an integer, the compiler will accept either one. And the two m=
ean very different things, with `return 5` immediately halting execution.<b=
r><br>That is a very nasty, completely <i>silent</i> breakage. That's b=
ad.<br><br>FYI: rules like the one you suggest gave us the <a href=3D"https=
://en.wikipedia.org/wiki/Most_vexing_parse" target=3D"_blank">Most Vexing P=
arse</a>. We should not deliberately add features like that again.<br><br>I=
f you had just introduced an actual name, that wouldn't be necessary.<b=
r><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"><div><=
div class=3D"gmail_quote"><div></div><div>There are some parsing ambiguitie=
s like:</div><div><br></div><div>=C2=A0 =C2=A0return(x);</div><div><br></di=
v><div>Is this an expression statement calling operator() of the return obj=
ect, or a return statement returning x.=C2=A0 These ambiguities would have =
to be resolved as part of the proposal (most likely "if it can be a re=
turn statement, it is a return statement").</div></div></div></div></b=
lockquote><div><br>Which would limit the ways in which you can use this imp=
licit variable. You can't even call operator() on it without shenanigan=
s (like `(return)()` or whatever). Though at least that may well be a noisy=
breakage.<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"><div><div class=3D"gmail_quote"><div></div><blockquote class=3D"gm=
ail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le=
ft:1ex"><div>Is it default initialized or value initialized.</div></blockqu=
ote><div><br></div><div>It is as-if it was declared without an initializer:=
</div><div><br></div><div>=C2=A0 T f() {</div><div>=C2=A0 =C2=A0 T x; =C2=
=A0// <-- like this</div><div>=C2=A0</div><div>I can't remember whic=
h this implies off the top of my head.</div></div></div></div></blockquote>=
<div><br>That's <a href=3D"http://en.cppreference.com/w/cpp/language/de=
fault_initialization" target=3D"_blank">default initialization</a>, so for =
many types, they go uninitialized. That's generally considered bad thes=
e days. Or at least, it's not good for it to be the default case.<br><b=
r></div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8=
ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div =
class=3D"gmail_quote"><div></div><blockquote class=3D"gmail_quote" style=3D=
"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div> What =
if the type doesn't have a default constructor,</div></blockquote><div>=
<br></div><div>Ill-formed.</div></div></div></div></blockquote><blockquote =
style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);pa=
dding-left:1ex" class=3D"gmail_quote"><div>=C2=A0</div></blockquote><div></=
div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div clas=
s=3D"gmail_quote"><div></div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div> or if I w=
ant to call a different constructor? </div></blockquote><div><br></div><div=
>With the third implicit form, you can't.</div></div></div></div></bloc=
kquote><div><br>Doesn't this restriction significantly limit how much u=
sers can use this "common pattern"? Even if only 30% of uses of t=
his pattern used a non-default constructor, that's still almost 1/3rd o=
f potential users who can't use this feature.<br><br>So ultimately, all=
they save is a return at the bottom of the function. Again, is that <i>one=
line</i> worth the syntactic burden?<br>=C2=A0</div><blockquote class=3D"g=
mail_quote" style=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"><div></d=
iv><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left=
:1px #ccc solid;padding-left:1ex"><div>What if the default constructor thro=
ws; how would you catch the exception?<br></div></blockquote><div><br></div=
><div>I can't remember if this works:</div><div><br></div><div>=C2=A0 =
=C2=A0 void f() {</div><div>=C2=A0 =C2=A0 =C2=A0 return++;</div><div>=C2=A0=
=C2=A0 } catch (...) {</div><div>=C2=A0 =C2=A0 }</div><div><br></div><div>=
But if it does, it would catch an exception thrown from the return construc=
tor.</div></div></div></div></blockquote><div><br>Well, that particular syn=
tax doesn't work. But it is possible to create <a href=3D"http://en.cpp=
reference.com/w/cpp/language/function-try-block" target=3D"_blank">function=
-level try/catch blocks</a>.<br><br>But really, you shouldn't encourage=
that.<br>=C2=A0</div><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"l=
tr"><div><div class=3D"gmail_quote"><div></div><div></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div>And most importantly, why is this at all worthwhile? Ser=
iously, is declaring a variable and returning it really that hard?<br></div=
></blockquote><div>=C2=A0</div><div>The motivation is mainly providing a te=
rser syntax for an, in my opinion, common pattern (as an example, a similar=
motivation to, although much smaller than, lambdas).</div></div></div></di=
v></blockquote><div><br>You're saving 2 lines of code. In a function th=
at's just 10 lines long (including declaration and {}s), that's onl=
y a 20% reduction in code size. And the shorter said code is, the <i>less</=
i> likely it is that you will need to use this pattern.<br><br>And you can =
only save two lines of code if you use the default-construct-followed-by-in=
itialization pattern. If you need to use an actual constructor, you save...=
one line of code. Only 10% in a 10 line function.<br><br>If a full quarter=
of your functions use the first pattern (and I rather doubt it's even =
that common), you will save maybe 5% of actual lines of text.<br><br>So eve=
n if this pattern were common, you ultimately don't save much. And the =
downsides of the feature make=C2=A0 it harder to reason about code (thanks =
to `return` ambiguities), introduce unnamed variables, and make functions b=
ehave in a way that is very new (automatically returning values).<br><br>La=
mbdas save you tons of very difficult-to-write code, especially if they cap=
ture values. Thus far, your feature saves you 2 lines of trivial-to-write c=
ode.<br><br>So I'm failing to see the cost/benefit here.<br></div>
<p></p>
-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</blockquote></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--94eb2c032818e9255d0520e8613a--
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Tue, 29 Sep 2015 16:27:34 -0400
Raw View
--089e013d0ffce685090520e8a4c9
Content-Type: text/plain; charset=UTF-8
On Tue, Sep 29, 2015 at 4:08 PM, little3lue <little3lue@gmail.com> wrote:
> Some languages allow creating a named variable for the return type, as
> part of the function definition.
>
> E.g. strawman:
>
> // foo.h
> Foo getFoo();
>
> // foo.cpp
> (Foo foo) getFoo() {
> // foo is initialized and "automatically returned" unless another value
> is explicitly returned
> foo.fizzle();
> }
>
> // Or maybe:
> auto getFoo -> Foo foo {
> }
>
> -Michal
>
> On Tue, Sep 29, 2015 at 10:09 AM Nicol Bolas <jmckesson@gmail.com> wrote:
>
>> On Tuesday, September 29, 2015 at 2:28:58 AM UTC-4, Andrew Tomazos wrote:
>>>
>>>
>>>>> std::vector<std::pair<int,int>> build_points() {
>>>>> while (c) return.emplace_back(g(c),h(c));
>>>>> }
>>>>>
>>>>
>>
And some languages allow you to use the function name:
Foo getFoo() {
getFoo = lookup(...);
}
I don't like any of these suggestions (just aesthetically, they don't
look/feel like C++ to me) and don't think the committee should spend time
on this area - I don't think it is worth it. Committee time is finite, and
expensive. There are better things to spend it on. IMO.
(and feel free to say the same of my proposals, if that's your opinion)
Tony
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--089e013d0ffce685090520e8a4c9
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 Tue, Sep 29, 2015 at 4:08 PM, little3lue <span dir=3D"ltr"><<a hr=
ef=3D"mailto:little3lue@gmail.com" target=3D"_blank">little3lue@gmail.com</=
a>></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">Som=
e languages allow creating a named variable for the return type, as part of=
the function definition.<div><br></div><div>E.g. strawman:</div><div><br><=
/div><div>// foo.h</div><div>Foo getFoo();</div><div><br></div><div>// foo.=
cpp</div><div>(Foo foo) getFoo() {</div><div>=C2=A0 // foo is initialized a=
nd "automatically returned" unless another value is explicitly re=
turned</div><div>=C2=A0 foo.fizzle();</div><div>}</div><div><br></div><div>=
// Or maybe:</div><div>auto getFoo -> Foo foo {</div><div>}</div><div><b=
r></div><div>-Michal</div></div><div><div><br><div class=3D"gmail_quote"><d=
iv dir=3D"ltr">On Tue, Sep 29, 2015 at 10:09 AM Nicol Bolas <<a href=3D"=
mailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>> w=
rote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex">On Tuesday, September 29, 201=
5 at 2:28:58 AM UTC-4, Andrew Tomazos wrote:<blockquote class=3D"gmail_quot=
e" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-l=
eft:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><span><blockquote class=3D"gmail_quote" style=3D"margin:0;mar=
gin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr=
"><br><div><div>=C2=A0 std::vector<std::pair<int,int>> build_po=
ints()=C2=A0{</div>=C2=A0 =C2=A0 while (c) return.emplace_back(g(c),h(c));<=
div>=C2=A0 }<br></div></div></div></blockquote></span><div></div></blockquo=
te></div></div></div></blockquote><br></blockquote></div></div></div></bloc=
kquote><div><br><br></div><div>And some languages allow you to use the func=
tion name:<br><br></div><div>Foo getFoo() {<br></div><div>=C2=A0=C2=A0 getF=
oo =3D lookup(...);<br>}<br><br></div><div><br></div><div>I don't like =
any of these suggestions (just aesthetically, they don't look/feel like=
C++ to me) and don't think the committee should spend time on this are=
a - I don't think it is worth it.=C2=A0 Committee time is finite, and e=
xpensive.=C2=A0 There are better things to spend it on. IMO.<br></div><div>=
(and feel free to say the same of my proposals, if that's your opinion)=
<br><br></div><div>Tony<br>=C2=A0<br></div></div></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--089e013d0ffce685090520e8a4c9--
.
Author: Matthew Woehlke <mwoehlke.floss@gmail.com>
Date: Wed, 30 Sep 2015 15:30:57 -0400
Raw View
On 2015-09-29 01:27, Nicol Bolas wrote:
> Also, the whole "implicit return" thing sounds like a can of worms. C++ as
> a language is not required to diagnose failure to return a value from a
> function with a return value.
....which, IMO, is a travesty :-).
Well, okay, maybe not that it's not *required*, but that it isn't
commonly *done*. (Is it actually forbidden for a compiler to do so?)
IMO, -Werror=return-type ought to be default behavior.
Back on topic, I agree that implicit returns sound horrible...
> I'm also not very convinced of your "common pattern" being that common.
I've written '<decl> result; ... return result;' often enough that I
wouldn't mind a shortcut. I'd be potentially interested in this much of
the proposal:
auto foo(...) // arguments not important
{
while (...)
return.emplace_back(...);
return;
}
That is, one can use 'return' as a local variable; doing so implicitly
declares a mutable 'decltype(return)' variable at the latest point in
the outermost scope in which it is referenced before it is referenced.
If this syntax is used, a 'return' with no value implicitly returns this
implicit result variable (and counts as a reference to the same for the
purpose of the previous rule).
That said, it would be much better (and I would prefer) if the implicit
variable could be named something like '__result'...
> How would such things work with conditional returns? Would you have
> to structure your code to have all conditionals coalesce at the end?
No. An explicit 'return' is still required. You can explicitly return
anything, at any point, as always.
> Or would `return` automatically return the value?
Yes.
> Why would you *want* an unnamed variable? Is typing a variable name somehow
> complicated? Is it an onerous burden for the user?
Yes? :-) (See also requests for anonymous variables for another example
where developers don't want to have to be bothered giving things names.)
Declaring and naming the temporary variable used to aggregate the result
is unnecessary overhead.
> On Tuesday, September 29, 2015 at 12:10:18 AM UTC-4, Andrew Tomazos wrote:
>> Now suppose we said that if the expression return appears in a function,
>> the auto return declaration is created implicitly:
>>
>> std::vector<std::pair<int,int>> build_points() {
>> while (c) return.emplace_back(g(c),h(c));
>> }
>
> Now you've taken away anything that looks even *remotely* like a variable
> declaration (or C++ in general). This raises a number of questions.
>
> Where does this variable get declared? When does its constructor get
> called?
See above.
> *How* does this variable get declared; does it get default
> constructed?
Yes. (Well, "like 'auto&& __result = decltype(return){}" would be fine,
just so long as it isn't trying to call some non-obvious ctor.)
> Is it default initialized or value initialized. What if the
> type doesn't have a default constructor, or if I want to call a different
> constructor?
Don't use this feature for those cases. In such cases, you need an
explicit declaration anyway, so the feature (assuming we get
'decltype(return)') is of minimal benefit.
> What if the default constructor throws; how would you catch
> the exception?
Wrap any reference to it in a try-catch, so that the declaration scope
is the 'try { ... }'.
The technical problems seem solvable. Does seem like a lot of effort for
the benefit, though.
On 2015-09-29 10:09, Nicol Bolas wrote:
> You're talking about deliberately declaring an unnamed *variable*.
> That's very new for C++.
....but *not* the first time it's been requested. (OT: And, really...
having to name variables that exist only for the side effects of their
ctor/dtor *is* annoying...)
--
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Wed, 30 Sep 2015 15:41:12 -0400
Raw View
--001a113fb8c0ebd6bb0520fc1c46
Content-Type: text/plain; charset=UTF-8
On Wed, Sep 30, 2015 at 3:30 PM, Matthew Woehlke <mwoehlke.floss@gmail.com>
wrote:
>
> I've written '<decl> result; ... return result;' often enough that I
> wouldn't mind a shortcut. I'd be potentially interested in this much of
> the proposal:
>
> auto foo(...) // arguments not important
> {
> while (...)
> return.emplace_back(...);
> return;
> }
>
> That is, one can use 'return' as a local variable;
In that case, I'd expect that last line to be
return return;
And (sadly?) I think I'd be more comfortable with that.
Tony
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--001a113fb8c0ebd6bb0520fc1c46
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 Wed, Sep 30, 2015 at 3:30 PM, Matthew Woehlke <span dir=3D"ltr"><=
<a href=3D"mailto:mwoehlke.floss@gmail.com" target=3D"_blank">mwoehlke.flos=
s@gmail.com</a>></span> wrote:<br><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span c=
lass=3D""><br>
</span>I've written '<decl> result; ... return result;' o=
ften enough that I<br>
wouldn't mind a shortcut. I'd be potentially interested in this muc=
h of<br>
the proposal:<br>
<br>
=C2=A0 auto foo(...) // arguments not important<br>
=C2=A0 {<br>
=C2=A0 =C2=A0 while (...)<br>
=C2=A0 =C2=A0 =C2=A0 return.emplace_back(...);<br>
=C2=A0 =C2=A0 return;<br>
=C2=A0 }<br>
<br>
That is, one can use 'return' as a local variable;</blockquote><div=
><br></div><div>In that case, I'd expect that last line to be<br><br></=
div><div>=C2=A0=C2=A0=C2=A0 return return;<br><br></div><div>And (sadly?) I=
think I'd be more comfortable with that.<br></div></div><br></div><div=
class=3D"gmail_extra">Tony<br><br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a113fb8c0ebd6bb0520fc1c46--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Wed, 30 Sep 2015 15:52:10 -0700 (PDT)
Raw View
------=_Part_7793_1246909813.1443653530901
Content-Type: multipart/alternative;
boundary="----=_Part_7794_31656051.1443653530902"
------=_Part_7794_31656051.1443653530902
Content-Type: text/plain; charset=UTF-8
On Wednesday, September 30, 2015 at 3:31:25 PM UTC-4, Matthew Woehlke wrote:
>
> On 2015-09-29 01:27, Nicol Bolas wrote:
> > Also, the whole "implicit return" thing sounds like a can of worms. C++
> as
> > a language is not required to diagnose failure to return a value from a
> > function with a return value.
>
> ...which, IMO, is a travesty :-).
>
Can't say I disagree ;)
> Well, okay, maybe not that it's not *required*, but that it isn't
> commonly *done*. (Is it actually forbidden for a compiler to do so?)
>
It's not forbidden, and most compilers do it to some degree by default (I
think). It's just not a required compile error, since it's possible for
valid code to work:
int i = val & 0x1;
switch(i)
{
case 0:
return ...;
case 1:
return ...;
}
//no return
Does the user need to write a return statement below there, where logically
code will never reach? The question quickly becomes the halting problem. So
compilers are required to allow this, only with massive UB if `//no return`
is actually encountered.
It's the best way to avoid false positives.
> I'm also not very convinced of your "common pattern" being that common.
>
> I've written '<decl> result; ... return result;' often enough that I
> wouldn't mind a shortcut. I'd be potentially interested in this much of
> the proposal:
>
> auto foo(...) // arguments not important
> {
> while (...)
> return.emplace_back(...);
> return;
> }
>
> That is, one can use 'return' as a local variable; doing so implicitly
> declares a mutable 'decltype(return)' variable at the latest point in
> the outermost scope in which it is referenced before it is referenced.
> If this syntax is used, a 'return' with no value implicitly returns this
> implicit result variable (and counts as a reference to the same for the
> purpose of the previous rule).
>
Hmm. The thing about putting the variable at the top is that if it throws
on default construction, you haven't broken anything, since the only
variables that have been created are the parameters.
And sure, everybody ought to be using RAII for exception cleanup (even
through GCL's finally stuff). But throwing from the middle of a function,
with the source of the exception being an object that has no actual
declaration (not to mention the rules you gave about where the variable
gets declared)?
Isn't that ... dangerously confusing for tracking down errors?
> > Or would `return` automatically return the value?
>
> Yes.
>
So can you choose to return a different value?
> > Why would you *want* an unnamed variable? Is typing a variable name
> somehow
> > complicated? Is it an onerous burden for the user?
>
> Yes? :-) (See also requests for anonymous variables for another example
> where developers don't want to have to be bothered giving things names.)
>
The difference is that, in those cases, the anonymous variable can't be
referenced. Here it can. Also, in those cases, you may need to create
multiple such variables. You can only create one return value.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_7794_31656051.1443653530902
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Wednesday, September 30, 2015 at 3:31:25 PM UTC-4, Matt=
hew Woehlke wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 2015-09-2=
9 01:27, Nicol Bolas wrote:
<br>> Also, the whole "implicit return" thing sounds like a ca=
n of worms. C++ as=20
<br>> a language is not required to diagnose failure to return a value f=
rom a=20
<br>> function with a return value.
<br>
<br>...which, IMO, is a travesty :-).<br></blockquote><div><br>Can't sa=
y I disagree ;)<br>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"m=
argin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"=
>
Well, okay, maybe not that it's not *required*, but that it isn't
<br>commonly *done*. (Is it actually forbidden for a compiler to do so?)<br=
></blockquote><div><br>It's not forbidden, and most compilers do it to =
some degree by default (I think). It's just not a required compile erro=
r, since it's possible for valid code to work:<br><br><div class=3D"pre=
ttyprint" style=3D"background-color: rgb(250, 250, 250); border-color: rgb(=
187, 187, 187); border-style: solid; border-width: 1px; word-wrap: break-wo=
rd;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span style=
=3D"color: #008;" class=3D"styled-by-prettify">int</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> i </span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> val </span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">&</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"> </span><span style=3D"color: #066;" class=3D"styled-by-pre=
ttify">0x1</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br><br><=
/span><span style=3D"color: #008;" class=3D"styled-by-prettify">switch</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify">i</span><span style=3D"c=
olor: #660;" 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">{</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"><br></span><span style=3D"color: #008;" class=3D"styled-b=
y-prettify">case</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> </span><span style=3D"color: #066;" class=3D"styled-by-prettify">0</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">:</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 </span><sp=
an style=3D"color: #008;" class=3D"styled-by-prettify">return</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">...;</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #008;"=
class=3D"styled-by-prettify">case</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #066;" class=3D"style=
d-by-prettify">1</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">:</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br=
>=C2=A0 </span><span style=3D"color: #008;" class=3D"styled-by-prettify">re=
turn</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">...;</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">}</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"><br><br></span><span style=3D"color:=
#800;" class=3D"styled-by-prettify">//no return</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"><br></span></div></code></div><br>Doe=
s the user need to write a return statement below there, where logically co=
de will never reach? The question quickly becomes the halting problem. So c=
ompilers are required to allow this, only with massive UB if `//no return` =
is actually encountered.<br><br>It's the best way to avoid false positi=
ves.<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
> I'm also not very convinced of your "common pattern" bei=
ng that common.
<br>
<br>I've written '<decl> result; ... return result;' ofte=
n enough that I
<br>wouldn't mind a shortcut. I'd be potentially interested in this=
much of
<br>the proposal:
<br>
<br>=C2=A0 auto foo(...) // arguments not important
<br>=C2=A0 {
<br>=C2=A0 =C2=A0 while (...)
<br>=C2=A0 =C2=A0 =C2=A0 return.emplace_back(...);
<br>=C2=A0 =C2=A0 return;
<br>=C2=A0 }
<br>
<br>That is, one can use 'return' as a local variable; doing so imp=
licitly
<br>declares a mutable 'decltype(return)' variable at the latest po=
int in
<br>the outermost scope in which it is referenced before it is referenced.
<br>If this syntax is used, a 'return' with no value implicitly ret=
urns this
<br>implicit result variable (and counts as a reference to the same for the
<br>purpose of the previous rule).<br></blockquote><div><br>Hmm. The thing =
about putting the variable at the top is that if it throws on default const=
ruction, you haven't broken anything, since the only variables that hav=
e been created are the parameters.<br><br>And sure, everybody ought to be u=
sing RAII for exception cleanup (even through GCL's finally stuff). But=
throwing from the middle of a function, with the source of the exception b=
eing an object that has no actual declaration (not to mention the rules you=
gave about where the variable gets declared)?<br><br>Isn't that ... da=
ngerously confusing for tracking down errors?<br>=C2=A0</div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px =
#ccc solid;padding-left: 1ex;">
> Or would `return` automatically return the value?
<br>
<br>Yes.<br></blockquote><div><br>So can you choose to return a different v=
alue?<br>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
> Why would you *want* an unnamed variable? Is typing a variable name so=
mehow=20
<br>> complicated? Is it an onerous burden for the user?
<br>
<br>Yes? :-) (See also requests for anonymous variables for another example
<br>where developers don't want to have to be bothered giving things na=
mes.)<br></blockquote><div><br>The difference is that, in those cases, the =
anonymous variable can't be referenced. Here it can. Also, in those cas=
es, you may need to create multiple such variables. You can only create one=
return value.<br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_7794_31656051.1443653530902--
------=_Part_7793_1246909813.1443653530901--
.
Author: Arthur O'Dwyer <arthur.j.odwyer@gmail.com>
Date: Wed, 30 Sep 2015 15:56:07 -0700 (PDT)
Raw View
------=_Part_9720_640582435.1443653767270
Content-Type: multipart/alternative;
boundary="----=_Part_9721_545280241.1443653767271"
------=_Part_9721_545280241.1443653767271
Content-Type: text/plain; charset=UTF-8
Turning "return" into a primary-expression is a non-starter.
int foo() {
return+1;
}
int bar() {
return(1);
}
and probably some really crazy arbitrary-lookahead-requiring things with
lambda syntax: is return[a=1] an array indexing expression or a return
statement returning a lambda?
So we can forget about that syntax and go back to the whiteboard... which
means re-confronting the question of "what problem is it that we're really
trying to solve, again?" Is it that our shortest functions aren't short
enough? Is it that we don't feel in control enough of RVO and want to
annotate the "return-slot variable" for our own peace of mind? ...What's
the problem being solved?
On Wednesday, September 30, 2015 at 12:41:14 PM UTC-7, Tony V E wrote:
>
>
>
> On Wed, Sep 30, 2015 at 3:30 PM, Matthew Woehlke <mwoehlk...@gmail.com
> <javascript:>> wrote:
>
>>
>> I've written '<decl> result; ... return result;' often enough that I
>> wouldn't mind a shortcut. I'd be potentially interested in this much of
>> the proposal:
>>
>> auto foo(...) // arguments not important
>> {
>> while (...)
>> return.emplace_back(...);
>> return;
>> }
>>
>> That is, one can use 'return' as a local variable;
>
>
> In that case, I'd expect that last line to be
>
> return return;
>
> And (sadly?) I think I'd be more comfortable with that.
>
> Tony
>
>
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_9721_545280241.1443653767271
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Turning "return" into a primary-expression =
is a non-starter.</div><div><br></div><div>=C2=A0 =C2=A0 int foo() {</div><=
div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 return+1;</div><div>=C2=A0 =C2=A0 }</div><d=
iv><br></div><div>=C2=A0 =C2=A0 int bar() {</div><div>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 return(1);</div><div>=C2=A0 =C2=A0 }</div><div><br></div><div>and pr=
obably some really crazy arbitrary-lookahead-requiring things with lambda s=
yntax: is return[a=3D1] an array indexing expression or a return statement =
returning a lambda?</div><div><br></div><div>So we can forget about that sy=
ntax and go back to the whiteboard... which means re-confronting the questi=
on of "what problem is it that we're really trying to solve, again=
?" =C2=A0Is it that our shortest functions aren't short enough? =
=C2=A0Is it that we don't feel in control enough of RVO and want to ann=
otate the "return-slot variable" for our own peace of mind? =C2=
=A0...What's the problem being solved?</div><div><br></div><br>On Wedne=
sday, September 30, 2015 at 12:41:14 PM UTC-7, Tony V E wrote:<blockquote c=
lass=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px=
#ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><br><div><br><div class=3D=
"gmail_quote">On Wed, Sep 30, 2015 at 3:30 PM, Matthew Woehlke <span dir=3D=
"ltr"><<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=
=3D"Y54BkKZdCgAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascri=
pt:';return true;" onclick=3D"this.href=3D'javascript:';return =
true;">mwoehlk...@gmail.com</a>></span> wrote:<br><blockquote class=3D"g=
mail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-l=
eft:1ex"><span><br>
</span>I've written '<decl> result; ... return result;' o=
ften enough that I<br>
wouldn't mind a shortcut. I'd be potentially interested in this muc=
h of<br>
the proposal:<br>
<br>
=C2=A0 auto foo(...) // arguments not important<br>
=C2=A0 {<br>
=C2=A0 =C2=A0 while (...)<br>
=C2=A0 =C2=A0 =C2=A0 return.emplace_back(...);<br>
=C2=A0 =C2=A0 return;<br>
=C2=A0 }<br>
<br>
That is, one can use 'return' as a local variable;</blockquote><div=
><br></div><div>In that case, I'd expect that last line to be<br><br></=
div><div>=C2=A0=C2=A0=C2=A0 return return;<br><br></div><div>And (sadly?) I=
think I'd be more comfortable with that.<br></div></div><br></div><div=
>Tony<br><br></div></div>
</blockquote></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_9721_545280241.1443653767271--
------=_Part_9720_640582435.1443653767270--
.
Author: Matthew Woehlke <mwoehlke.floss@gmail.com>
Date: Thu, 01 Oct 2015 12:58:15 -0400
Raw View
On 2015-09-30 18:52, Nicol Bolas wrote:
> On Wednesday, September 30, 2015 at 3:31:25 PM UTC-4, Matthew Woehlke wro=
te:
>> On 2015-09-29 01:27, Nicol Bolas wrote:=20
>>> Also, the whole "implicit return" thing sounds like a can of=20
>>> worms. C++ as a language is not required to diagnose failure to=20
>>> return a value from afunction with a return value.
>>=20
>> ...which, IMO, is a travesty :-).
>=20
> Can't say I disagree ;)
>=20
>> Well, okay, maybe not that it's not *required*, but that it isn't=20
>> commonly *done*. (Is it actually forbidden for a compiler to do so?)
>=20
> It's not forbidden, and most compilers do it to some degree by default (I=
=20
> think).
At least gcc 4.8 doesn't make it an error by default; AFAIK that hasn't
changed, nor does clang make it an error either.
I'm not sure MSVC even has a warning.
> It's just not a required compile error, since it's possible for=20
> valid code to work:
>=20
> int i =3D val & 0x1;
>=20
> switch(i)
> {
> case 0:
> return ...;
> case 1:
> return ...;
> }
>=20
> //no return
First, to be clear, I'm not talking about cases where the last line in a
function is other than 'return'. I'm talking about cases where the
compiler determines that some plausible code path will result in
execution falling off the end of the function. This would exclude your
above example, and also e.g. code paths that dive into a [[noreturn]]
function. Getting that right seems like a QoI issue, and modern
compilers seem to already do a good job here. Moreover, I would expect
compilers to err on the side of caution and not issue a fatal diagnostic
if they aren't confident that there is really a problem. (Mind, I've
personally used -Werror=3Dreturn-type for some years now on pretty much
any software I build, and have yet to see a false positive.)
I wouldn't anyway propose to *mandate* a diagnostic, because it *is* a
hard problem to get right. I just wish compilers would default to making
this an error rather than a warning, especially in pathological cases
such as a function that can't *not* fall off the end (e.g. because it
contains no 'return' or [[noreturn]] calls *at all*)=C2=B9. And yes, I've
seen these in real code. (I'd even hazard to say that those are the
*majority* of the -Werror=3Dreturn-type errors I've seen, and from
functions with only a few lines of code in their bodies.)
(=C2=B9 I suppose you could have a function that is guaranteed to throw...
but if so, why is the return type non-void?)
Anyway, this is all fascinating, but OT :-).
>>> I'm also not very convinced of your "common pattern" being that common.=
=20
>>
>> [...] one can use 'return' as a local variable; doing so implicitly=20
>> declares a mutable 'decltype(return)' variable at the latest point in=20
>> the outermost scope in which it is referenced before it is referenced.=
=20
>> If this syntax is used, a 'return' with no value implicitly returns this=
=20
>> implicit result variable (and counts as a reference to the same for the=
=20
>> purpose of the previous rule).
>=20
> Hmm. The thing about putting the variable at the top is that if it throws=
=20
> on default construction, you haven't broken anything, since the only=20
> variables that have been created are the parameters.
Hmm, true, but OTOH if construction is expensive and you don't need it
until halfway through the function (after a bunch of other logic that
might early exit and return something else), then you've constructed and
destroyed an unused local for no reason.
> Isn't that ... dangerously confusing for tracking down errors?
You could always just not use exceptions? ;-)
That said, I can agree that's an issue. This is another feature that I
think would be nice and useful *if* we had it, but probably not worth
trying to standardize.
>>> Or would `return` automatically return the value?=20
>>
>> Yes.
>=20
> So can you choose to return a different value?
Yes. (The above might be unclear; "return;" - with no 'argument' -
returns the implicit result variable, "return <expr>;" returns "<expr>".)
--=20
Matthew
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
.