Topic: return type sugar (orthogonal to auto foo() {} )
Author: walter1234 <walter2bz@gmail.com>
Date: Thu, 12 Jun 2014 03:16:04 -0700 (PDT)
Raw View
------=_Part_87_22099948.1402568164130
Content-Type: text/plain; charset=UTF-8
Coming back to C++ from Rust, one thing begin to miss is the 2way type
inference: its a nice choice on their part, you write the types in the
signature, then the types in the body are inferred.
But perhaps a significant amount of this use could be covered by having
sugar to access the declared return type of a function within its own body.
imagine
auto foo( args... )->decltype(....some expression based on args...) {
return_type accumulator; // 'return_type' is a shortcut for
whatever this functions declared return type is..
... do stuff with accumulator...
return accumulator.
}
ways of doing that without a new keyword, perhaps 'decltype(return)' , any
other ideas..
In some ways this would go beyond what rust currently does. (rust can't yet
use an expression for the return type, although making it generic often
works because of how the return types are inferred by callers)
--
---
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_87_22099948.1402568164130
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Coming back to C++ from Rust, one thing begin to miss is t=
he 2way type inference: its a nice choice on their part, you write the type=
s in the signature, then the types in the body are inferred.<div><br></div>=
<div>But perhaps a significant amount of this use could be covered by havin=
g sugar to access the declared return type of a function within its own bod=
y.</div><div><br></div><div>imagine</div><div><br></div><div>auto foo( &nbs=
p;args... )->decltype(....some expression based on args...) {</div=
><div><br></div><div> return_type accumulator; &n=
bsp; // 'return_type' is a shortcut for whatever this functions decl=
ared return type is..</div><div> ... do stuff with accu=
mulator...</div><div><br></div><div> return accumulator.=
</div><div>}</div><div><br></div><div>ways of doing that without a new keyw=
ord, perhaps 'decltype(return)' , any other ideas..</div><div>In some ways =
this would go beyond what rust currently does. (rust can't yet use an expre=
ssion for the return type, although making it generic often works because o=
f how the return types are inferred by callers)</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_87_22099948.1402568164130--
.
Author: Maurice Bos <m-ou.se@m-ou.se>
Date: Thu, 12 Jun 2014 15:49:26 +0200
Raw View
decltype(return) sounds good. I wished quite a few times I could've
written this. (D has it in the form of typeof(return):
http://dlang.org/declaration.html#Typeof)
2014-06-12 12:16 GMT+02:00 walter1234 <walter2bz@gmail.com>:
> Coming back to C++ from Rust, one thing begin to miss is the 2way type
> inference: its a nice choice on their part, you write the types in the
> signature, then the types in the body are inferred.
>
> But perhaps a significant amount of this use could be covered by having
> sugar to access the declared return type of a function within its own body.
>
> imagine
>
> auto foo( args... )->decltype(....some expression based on args...) {
>
> return_type accumulator; // 'return_type' is a shortcut for
> whatever this functions declared return type is..
> ... do stuff with accumulator...
>
> return accumulator.
> }
>
> ways of doing that without a new keyword, perhaps 'decltype(return)' , any
> other ideas..
> In some ways this would go beyond what rust currently does. (rust can't yet
> use an expression for the return type, although making it generic often
> works because of how the return types are inferred by callers)
>
> --
>
> ---
> 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/.
.
Author: Sebastian Gesemann <s.gesemann@gmail.com>
Date: Thu, 12 Jun 2014 16:10:47 +0200
Raw View
On Thu, Jun 12, 2014 at 12:16 PM, walter1234 wrote:
> Coming back to C++ from Rust, one thing begin to miss is the 2way type
> inference: its a nice choice on their part, you write the types in the
> signature, then the types in the body are inferred.
>
> But perhaps a significant amount of this use could be covered by having
> sugar to access the declared return type of a function within its own body.
>
> imagine
>
> auto foo( args... )->decltype(....some expression based on args...) {
>
> return_type accumulator; // 'return_type' is a shortcut for
> whatever this functions declared return type is..
> ... do stuff with accumulator...
>
> return accumulator.
> }
>
> ways of doing that without a new keyword, perhaps 'decltype(return)' , any
> other ideas..
> In some ways this would go beyond what rust currently does. (rust can't yet
> use an expression for the return type, although making it generic often
> works because of how the return types are inferred by callers)
I'm not sure about the utility for such a short cut -- given the fact
that in C++14 you can do something like this:
// note: no trailing return type
auto foo(int x, double y) {
return x+y;
}
Compared to what you suggest, this is the other way around: The return
type can be deduced from whatever the function returns.
--
---
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: Mikhail Semenov <mikhailsemenov1957@gmail.com>
Date: Thu, 12 Jun 2014 16:03:03 +0100
Raw View
--047d7bfd01668f2e8404fba4db9f
Content-Type: text/plain; charset=UTF-8
You can already write:
auto foo(int x, double y)->decltype(x+y)
{
...
}
On 12 June 2014 15:10, Sebastian Gesemann <s.gesemann@gmail.com> wrote:
> On Thu, Jun 12, 2014 at 12:16 PM, walter1234 wrote:
> > Coming back to C++ from Rust, one thing begin to miss is the 2way type
> > inference: its a nice choice on their part, you write the types in the
> > signature, then the types in the body are inferred.
> >
> > But perhaps a significant amount of this use could be covered by having
> > sugar to access the declared return type of a function within its own
> body.
> >
> > imagine
> >
> > auto foo( args... )->decltype(....some expression based on args...) {
> >
> > return_type accumulator; // 'return_type' is a shortcut for
> > whatever this functions declared return type is..
> > ... do stuff with accumulator...
> >
> > return accumulator.
> > }
> >
> > ways of doing that without a new keyword, perhaps 'decltype(return)' ,
> any
> > other ideas..
> > In some ways this would go beyond what rust currently does. (rust can't
> yet
> > use an expression for the return type, although making it generic often
> > works because of how the return types are inferred by callers)
>
> I'm not sure about the utility for such a short cut -- given the fact
> that in C++14 you can do something like this:
>
> // note: no trailing return type
> auto foo(int x, double y) {
> return x+y;
> }
>
> Compared to what you suggest, this is the other way around: The return
> type can be deduced from whatever the function returns.
>
> --
>
> ---
> 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/.
--047d7bfd01668f2e8404fba4db9f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>You can already write:</div><div>auto foo(int x, doub=
le y)->decltype(x+y) </div><div>{<br>=C2=A0=C2=A0=C2=A0=C2=A0...<br>}<br=
></div></div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">=
On 12 June 2014 15:10, Sebastian Gesemann <span dir=3D"ltr"><<a href=3D"=
mailto:s.gesemann@gmail.com" target=3D"_blank">s.gesemann@gmail.com</a>>=
</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div>On Thu, Jun 12, 2014 at 12:16 PM, walte=
r1234 wrote:<br>
> Coming back to C++ from Rust, one thing begin to miss is the 2way type=
<br>
> inference: its a nice choice on their part, you write the types in the=
<br>
> signature, then the types in the body are inferred.<br>
><br>
> But perhaps a significant amount of this use could be covered by havin=
g<br>
> sugar to access the declared return type of a function within its own =
body.<br>
><br>
> imagine<br>
><br>
> auto foo( =C2=A0args... =C2=A0)->decltype(....some expression based=
on args...) {<br>
><br>
> =C2=A0 =C2=A0 =C2=A0 return_type =C2=A0accumulator; =C2=A0 =C2=A0 // &=
#39;return_type' is a shortcut for<br>
> whatever this functions declared return type is..<br>
> =C2=A0 =C2=A0 =C2=A0 ... do stuff with accumulator...<br>
><br>
> =C2=A0 =C2=A0 =C2=A0return accumulator.<br>
> }<br>
><br>
> ways of doing that without a new keyword, perhaps 'decltype(return=
)' , any<br>
> other ideas..<br>
> In some ways this would go beyond what rust currently does. (rust can&=
#39;t yet<br>
> use an expression for the return type, although making it generic ofte=
n<br>
> works because of how the return types are inferred by callers)<br>
<br>
</div>I'm not sure about the utility for such a short cut -- given the =
fact<br>
that in C++14 you can do something like this:<br>
<br>
=C2=A0 // note: no trailing return type<br>
=C2=A0 auto foo(int x, double y) {<br>
=C2=A0 =C2=A0 return x+y;<br>
=C2=A0 }<br>
<br>
Compared to what you suggest, this is the other way around: The return<br>
type can be deduced from whatever the function returns.<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
--<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%2Bunsubscribe@isocpp.org">std-propo=
sals+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/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--047d7bfd01668f2e8404fba4db9f--
.
Author: Sebastian Gesemann <s.gesemann@gmail.com>
Date: Thu, 12 Jun 2014 18:00:00 +0200
Raw View
On Thu, Jun 12, 2014 at 5:03 PM, Mikhail Semenov wrote:
> You can already write:
> auto foo(int x, double y)->decltype(x+y)
> {
> ...
> }
Everybody knows that. The original poster wants a way to refer to the
return in the function body type without repeating that expression.
Obviously, one way of writing this function so that x+y is only
mentioned once is to make use of C++14's return type deduction. But
from the looks of the topic of this discussion ("...orthogonal to auto
foo() {}"), the OP already knew that.
So, I'm not really sure what the point of your response was.
Cheers!
sg
--
---
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: walter1234 <walter2bz@gmail.com>
Date: Thu, 12 Jun 2014 12:14:20 -0700 (PDT)
Raw View
------=_Part_3921_12570385.1402600460518
Content-Type: text/plain; charset=UTF-8
auto foo(...) {return...} is certainly a great thing to have.
the benefit of the type being in the signature however, is discoverability
and documentation - you may see many single line function prototypes in a
header, or you may have function bodies hidden. You may search for a
function by virtue of knowing what you want it to create.
The use that made me think of this was prototyping, even when functions are
inline and in headers, you still sometimes want to prototype them above so
that other functions can refer to them. Sometimes you want to separate out
".h" with just prototypes and ".inl" with inline function bodies.
I realise it might be possible to address the 'documentation' issue with an
IDE, which can deduce the types and show you in autocomplete/or function
browsers.
--
---
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_3921_12570385.1402600460518
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">auto foo(...) {return...} is certainly a great thin=
g to have.<div><br><div>the benefit of the type being in the signature howe=
ver, is discoverability and documentation - you may see many single line fu=
nction prototypes in a header, or you may have function bodies hidden. &nbs=
p; You may search for a function by virtue of knowing what you want it to c=
reate.</div></div><div><br></div><div>The use that made me think of this wa=
s prototyping, even when functions are inline and in headers, you still som=
etimes want to prototype them above so that other functions can refer to th=
em. Sometimes you want to separate out ".h" with just prototypes and ".inl"=
with inline function bodies.</div><div><br></div><div>I realise it might b=
e possible to address the 'documentation' issue with an IDE, which can dedu=
ce the types and show you in autocomplete/or function browsers.</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_3921_12570385.1402600460518--
.
Author: mitchnull@gmail.com
Date: Fri, 13 Jun 2014 01:04:35 -0700 (PDT)
Raw View
------=_Part_214_29830601.1402646675584
Content-Type: text/plain; charset=UTF-8
How about:
auto foo(int bar, float baz) -> decltype(bar + baz) {
decltype(foo(bar, baz)) res = bar + baz;
return res;
}
this way you don't have to repeat the expression, you only need to change
the type of "res" if the function name / parameters change. Having
decltype(return) be just syntax sugar for the above would be nice and easy
to do, so I think it would be nice to have a proposal for this.
On Thursday, June 12, 2014 12:16:04 PM UTC+2, walter1234 wrote:
>
> Coming back to C++ from Rust, one thing begin to miss is the 2way type
> inference: its a nice choice on their part, you write the types in the
> signature, then the types in the body are inferred.
>
> But perhaps a significant amount of this use could be covered by having
> sugar to access the declared return type of a function within its own body.
>
> imagine
>
> auto foo( args... )->decltype(....some expression based on args...) {
>
> return_type accumulator; // 'return_type' is a shortcut for
> whatever this functions declared return type is..
> ... do stuff with accumulator...
>
> return accumulator.
> }
>
> ways of doing that without a new keyword, perhaps 'decltype(return)' , any
> other ideas..
> In some ways this would go beyond what rust currently does. (rust can't
> yet use an expression for the return type, although making it generic often
> works because of how the return types are inferred by callers)
>
--
---
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_214_29830601.1402646675584
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">How about:<div><br></div><div><div class=3D"prettyprint" s=
tyle=3D"border: 1px solid rgb(187, 187, 187); word-wrap: break-word; backgr=
ound-color: rgb(250, 250, 250);"><code class=3D"prettyprint"><div class=3D"=
subprettyprint"><span style=3D"color: #008;" class=3D"styled-by-prettify">a=
uto</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> foo</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span=
style=3D"color: #008;" class=3D"styled-by-prettify">int</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> bar</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">float</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> baz</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">)</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">->=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><s=
pan style=3D"color: #008;" class=3D"styled-by-prettify">decltype</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">bar </span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">+</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"> baz</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">)</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">{</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><=
br> </span><span style=3D"color: #008;" class=3D"styled-by-pre=
ttify">decltype</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">foo<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify">bar</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"> baz</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">))</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> res </span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"> bar </span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">+</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
baz</span><span style=3D"color: #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">return</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> res</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"><br></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><br></span></div></code></div><div><br=
>this way you don't have to repeat the expression, you only need to change =
the type of "res" if the function name / parameters change. Having de=
cltype(return) be just syntax sugar for the above would be nice and easy to=
do, so I think it would be nice to have a proposal for this.</div><div><br=
></div><br>On Thursday, June 12, 2014 12:16:04 PM UTC+2, walter1234 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">Coming back to=
C++ from Rust, one thing begin to miss is the 2way type inference: its a n=
ice choice on their part, you write the types in the signature, then the ty=
pes in the body are inferred.<div><br></div><div>But perhaps a significant =
amount of this use could be covered by having sugar to access the declared =
return type of a function within its own body.</div><div><br></div><div>ima=
gine</div><div><br></div><div>auto foo( args... )->decltype(=
.....some expression based on args...) {</div><div><br></div><div> &nb=
sp; return_type accumulator; // 'return_type' is=
a shortcut for whatever this functions declared return type is..</div><div=
> ... do stuff with accumulator...</div><div><br></div>=
<div> return accumulator.</div><div>}</div><div><br></di=
v><div>ways of doing that without a new keyword, perhaps 'decltype(return)'=
, any other ideas..</div><div>In some ways this would go beyond what rust =
currently does. (rust can't yet use an expression for the return type, alth=
ough making it generic often works because of how the return types are infe=
rred by callers)</div></div></blockquote></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_214_29830601.1402646675584--
.
Author: =?UTF-8?Q?David_Rodr=C3=ADguez_Ibeas?= <dibeas@ieee.org>
Date: Fri, 13 Jun 2014 09:12:37 -0400
Raw View
--001a113a2a2e7408f304fbb76e4e
Content-Type: text/plain; charset=UTF-8
On Thu, Jun 12, 2014 at 3:14 PM, walter1234 <walter2bz@gmail.com> wrote:
> auto foo(...) {return...} is certainly a great thing to have.
>
> the benefit of the type being in the signature however, is discoverability
> and documentation -
>
.... and being able to use the return type in an SFINAE context. [Personally
I believe that library code *should* always spell out the return type in
the signature, trailing return type is fine, return type being deduced not
so much].
This is a contrived example, but is concise enough to be sent over email:
std::string f(int);
void f(double);
template <typename T>
auto g(T value) {
return f(value);
}
template <typename T>
auto h(T value) -> decltype(g(value).size())
{
return g(type).size();
}
template <typename T>
size_t h(T value, ...) {
return size_t();
}
int main() {
h(1.0); // hard error!!
}
If the return type of 'g' had not been deduced the above would have
SFINAE-d out the first template and called the second overload of 'h'.
David
--
---
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/.
--001a113a2a2e7408f304fbb76e4e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
On Thu, Jun 12, 2014 at 3:14 PM, walter1234 <span dir=3D"ltr"><<a href=
=3D"mailto:walter2bz@gmail.com" target=3D"_blank">walter2bz@gmail.com</a>&g=
t;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">auto foo(...) {return...} =
=C2=A0 is certainly a great thing to have.<div><br><div>the benefit of the =
type being in the signature however, is discoverability and documentation -=
=C2=A0</div>
</div></div></blockquote><div><br>... and being able to use the return type=
in an SFINAE context. [Personally I believe that library code *should* alw=
ays spell out the return type in the signature, trailing return type is fin=
e, return type being deduced not so much].<br>
<br>This is a contrived example, but is concise enough to be sent over emai=
l:<br><br>std::string f(int);<br>void =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0f(d=
ouble);</div><div><br>template <typename T><br>auto g(T value) {<br>=
=C2=A0 =C2=A0 return f(value);<br>
}</div><div><br>template <typename T><br>auto h(T value) -> declty=
pe(g(value).size())<br>{<br>=C2=A0 =C2=A0 return g(type).size();<br>}<br>te=
mplate <typename T><br>size_t h(T value, ...) {<br>=C2=A0 =C2=A0 retu=
rn size_t();<br>
}<br><br>int main() {<br>=C2=A0 =C2=A0 h(1.0); =C2=A0 =C2=A0 =C2=A0 // hard=
error!!<br>}<br><br>If the return type of 'g' had not been deduced=
the above would have SFINAE-d out the first template and called the second=
overload of 'h'.<br>
<br>=C2=A0 =C2=A0 David<br><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 />
--001a113a2a2e7408f304fbb76e4e--
.
Author: =?UTF-8?Q?Andrzej_Krzemie=C5=84ski?= <akrzemi1@gmail.com>
Date: Fri, 13 Jun 2014 09:24:27 -0700 (PDT)
Raw View
------=_Part_317_24531460.1402676667554
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
W dniu czwartek, 12 czerwca 2014 12:16:04 UTC+2 u=C5=BCytkownik walter1234=
=20
napisa=C5=82:
>
> Coming back to C++ from Rust, one thing begin to miss is the 2way type=20
> inference: its a nice choice on their part, you write the types in the=20
> signature, then the types in the body are inferred.
>
> But perhaps a significant amount of this use could be covered by having=
=20
> sugar to access the declared return type of a function within its own bod=
y.
>
> imagine
>
> auto foo( args... )->decltype(....some expression based on args...) {
>
> return_type accumulator; // 'return_type' is a shortcut for=20
> whatever this functions declared return type is..
> ... do stuff with accumulator...
>
> return accumulator.
> }
>
> ways of doing that without a new keyword, perhaps 'decltype(return)' , an=
y=20
> other ideas..
> In some ways this would go beyond what rust currently does. (rust can't=
=20
> yet use an expression for the return type, although making it generic oft=
en=20
> works because of how the return types are inferred by callers)
>
=20
How about doing it the Go style:
=20
auto foo( args... ) -> decltype(....some expression based on args...)=20
accumulator
{ =20
do_stuff_with(accumulator);
return accumulator.
}
=20
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
------=_Part_317_24531460.1402676667554
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br>W dniu czwartek, 12 czerwca 2014 12:16:04 UTC+2 u=C5=
=BCytkownik walter1234 napisa=C5=82:<blockquote style=3D"margin: 0px 0px 0p=
x 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-l=
eft-width: 1px; border-left-style: solid;" class=3D"gmail_quote"><div dir=
=3D"ltr">Coming back to C++ from Rust, one thing begin to miss is the 2way =
type inference: its a nice choice on their part, you write the types in the=
signature, then the types in the body are inferred.<div><br></div><div>But=
perhaps a significant amount of this use could be covered by having sugar =
to access the declared return type of a function within its own body.</div>=
<div><br></div><div>imagine</div><div><br></div><div>auto foo( args..=
.. )->decltype(....some expression based on args...) {</div><div><b=
r></div><div> return_type accumulator; &nb=
sp; // 'return_type' is a shortcut for whatever this functions declared ret=
urn type is..</div><div> ... do stuff with accumulator.=
...</div><div><br></div><div> return accumulator.</div><d=
iv>}</div><div><br></div><div>ways of doing that without a new keyword, per=
haps 'decltype(return)' , any other ideas..</div><div>In some ways this wou=
ld go beyond what rust currently does. (rust can't yet use an expression fo=
r the return type, although making it generic often works because of how th=
e return types are inferred by callers)</div></div></blockquote><div> =
</div><div>How about doing it the Go style:</div><div> </div><div>auto=
foo( args... ) -> decltype(....some expression based on arg=
s...) accumulator<br>{ <br> do_stuff_with(accumulato=
r);<br> return accumulator.<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 />
------=_Part_317_24531460.1402676667554--
.
Author: =?UTF-8?Q?Andrzej_Krzemie=C5=84ski?= <akrzemi1@gmail.com>
Date: Fri, 13 Jun 2014 09:25:37 -0700 (PDT)
Raw View
------=_Part_297_30792517.1402676738095
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
W dniu pi=C4=85tek, 13 czerwca 2014 18:24:28 UTC+2 u=C5=BCytkownik Andrzej=
=20
Krzemie=C5=84ski napisa=C5=82:
>
>
> W dniu czwartek, 12 czerwca 2014 12:16:04 UTC+2 u=C5=BCytkownik walter123=
4=20
> napisa=C5=82:
>>
>> Coming back to C++ from Rust, one thing begin to miss is the 2way type=
=20
>> inference: its a nice choice on their part, you write the types in the=
=20
>> signature, then the types in the body are inferred.
>>
>> But perhaps a significant amount of this use could be covered by having=
=20
>> sugar to access the declared return type of a function within its own bo=
dy.
>>
>> imagine
>>
>> auto foo( args... )->decltype(....some expression based on args...) {
>>
>> return_type accumulator; // 'return_type' is a shortcut for=
=20
>> whatever this functions declared return type is..
>> ... do stuff with accumulator...
>>
>> return accumulator.
>> }
>>
>> ways of doing that without a new keyword, perhaps 'decltype(return)' ,=
=20
>> any other ideas..
>> In some ways this would go beyond what rust currently does. (rust can't=
=20
>> yet use an expression for the return type, although making it generic of=
ten=20
>> works because of how the return types are inferred by callers)
>>
> =20
> How about doing it the Go style:
> =20
> auto foo( args... ) -> decltype(....some expression based on args...)=
=20
> accumulator
> { =20
> do_stuff_with(accumulator);
> return accumulator.
> }
>
=20
Or even w/o return statement because it is obvious what we return:
=20
auto foo( args... ) -> decltype(....some expression based on args...)=20
accumulator
{=20
do_stuff_with(accumulator);
// no return (and no UB)
}
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
------=_Part_297_30792517.1402676738095
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br>W dniu pi=C4=85tek, 13 czerwca 2014 18:24:28 UTC+2 u=
=C5=BCytkownik Andrzej Krzemie=C5=84ski napisa=C5=82:<blockquote style=3D"m=
argin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 20=
4, 204); border-left-width: 1px; border-left-style: solid;" class=3D"gmail_=
quote"><div dir=3D"ltr"><br>W dniu czwartek, 12 czerwca 2014 12:16:04 UTC+2=
u=C5=BCytkownik walter1234 napisa=C5=82:<blockquote style=3D"margin: 0px 0=
px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); bor=
der-left-width: 1px; border-left-style: solid;" class=3D"gmail_quote"><div =
dir=3D"ltr">Coming back to C++ from Rust, one thing begin to miss is the 2w=
ay type inference: its a nice choice on their part, you write the types in =
the signature, then the types in the body are inferred.<div><br></div><div>=
But perhaps a significant amount of this use could be covered by having sug=
ar to access the declared return type of a function within its own body.</d=
iv><div><br></div><div>imagine</div><div><br></div><div>auto foo( arg=
s... )->decltype(....some expression based on args...) {</div><div=
><br></div><div> return_type accumulator; =
// 'return_type' is a shortcut for whatever this functions declared =
return type is..</div><div> ... do stuff with accumulat=
or...</div><div><br></div><div> return accumulator.</div=
><div>}</div><div><br></div><div>ways of doing that without a new keyword, =
perhaps 'decltype(return)' , any other ideas..</div><div>In some ways this =
would go beyond what rust currently does. (rust can't yet use an expression=
for the return type, although making it generic often works because of how=
the return types are inferred by callers)</div></div></blockquote><div>&nb=
sp;</div><div>How about doing it the Go style:</div><div> </div><div>a=
uto foo( args... ) -> decltype(....some expression based on =
args...) accumulator<br>{ <br> do_stuff_with(accumul=
ator);<br> return accumulator.<br>}</div></div></blockquote><div>&nbs=
p;</div><div>Or even w/o return statement because it is obvious what we ret=
urn:</div><div> </div><div>auto foo( args... ) -> decltype(....so=
me expression based on args...) accumulator<br>{ <br> do_stu=
ff_with(accumulator);<br> // no return (and no UB)<br>}</d=
iv></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_297_30792517.1402676738095--
.