Topic: Allow decltype(auto) in trailing return type.


Author: tomaszkam@gmail.com
Date: Tue, 18 Jun 2013 10:54:19 -0700 (PDT)
Raw View
------=_Part_856_10098986.1371578059042
Content-Type: text/plain; charset=ISO-8859-1

The accepted N3638 Return type deduction for normal functions<http://isocpp.org/files/papers/N3638.html>paper allows auto return type in trailing return type for the usage in
lambda, but disallows decltype(auto) in trailing return type.

The delctype(auto) may be usefful with combination with polymorphic
lambdas.
For example implementation of  perfect forwarding wrapper for normal
functions (as proposed in
https://dl.dropboxusercontent.com/u/14327987/functional_cpp.html).
  [](auto&&... args) -> decltype(auto) { return
id(std::forward<delctype(args)>(args)...; }
Without using decltype(auto) there is no way to correctly forward
references returned form functions invoked in polymorphic lambdas.

Was there any reason to disallow decltype(auto) in trailing return type
beyond not know use examples? In addition this will remove one last
difference between trailing return type and normal return type declaration.

--

---
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_856_10098986.1371578059042
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

The accepted <a href=3D"http://isocpp.org/files/papers/N3638.html">N3638 Re=
turn type deduction for normal functions</a> paper allows auto return type =
in trailing return type for the usage in lambda, but disallows decltype(aut=
o) in trailing return type.<br><br>The delctype(auto) may be usefful with c=
ombination with polymorphic lambdas. <br>For example implementation of&nbsp=
; perfect forwarding wrapper for normal functions (as proposed in <a href=
=3D"https://dl.dropboxusercontent.com/u/14327987/functional_cpp.html">https=
://dl.dropboxusercontent.com/u/14327987/functional_cpp.html</a>).<br><span =
style=3D"font-family: courier new,monospace;">&nbsp; [](auto&amp;&amp;... a=
rgs) -&gt; decltype(auto) { return id(std::forward&lt;delctype(args)&gt;(ar=
gs)...; }</span><br>Without using decltype(auto) there is no way to correct=
ly forward references returned form functions invoked in polymorphic lambda=
s.<br><br>Was there any reason to disallow decltype(auto) in trailing retur=
n type beyond not know use examples? In addition this will remove one last =
difference between trailing return type and normal return type declaration.=
<br>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />
&nbsp;<br />
&nbsp;<br />

------=_Part_856_10098986.1371578059042--

.


Author: Richard Smith <richard@metafoo.co.uk>
Date: Tue, 18 Jun 2013 10:57:36 -0700
Raw View
On Tue, Jun 18, 2013 at 10:54 AM,  <tomaszkam@gmail.com> wrote:
> The accepted N3638 Return type deduction for normal functions paper allows
> auto return type in trailing return type for the usage in lambda, but
> disallows decltype(auto) in trailing return type.

What makes you think that? That was not the intent and I cannot see
how to interpret the wording that way.

--

---
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: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Tue, 18 Jun 2013 21:01:23 +0300
Raw View
--20cf302d4e6046b2c704df718035
Content-Type: text/plain; charset=ISO-8859-1

On 18 June 2013 20:57, Richard Smith <richard@metafoo.co.uk> wrote:

> On Tue, Jun 18, 2013 at 10:54 AM,  <tomaszkam@gmail.com> wrote:
> > The accepted N3638 Return type deduction for normal functions paper
> allows
> > auto return type in trailing return type for the usage in lambda, but
> > disallows decltype(auto) in trailing return type.
>
> What makes you think that? That was not the intent and I cannot see
> how to interpret the wording that way.
>
>
>
Me neither, the wording defines both auto and decltype(auto) to be
placeholder types, and
then allows both for trailing-return-type.

"The auto and decltype(auto) type-specifiers designate a placeholder
type..."

"The auto type-specifier may placeholder type can appear with a function
declarator in the *decl-specifier-seq*, *type-specifier-seq*, *
conversion-function-id*, or *trailing-return-type*..."

--

---
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/.



--20cf302d4e6046b2c704df718035
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 18 June 2013 20:57, Richard Smith <span dir=3D"ltr">&lt;<a href=
=3D"mailto:richard@metafoo.co.uk" target=3D"_blank">richard@metafoo.co.uk</=
a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex"><div class=3D"im">On Tue,=
 Jun 18, 2013 at 10:54 AM, =A0&lt;<a href=3D"mailto:tomaszkam@gmail.com">to=
maszkam@gmail.com</a>&gt; wrote:<br>

&gt; The accepted N3638 Return type deduction for normal functions paper al=
lows<br>
&gt; auto return type in trailing return type for the usage in lambda, but<=
br>
&gt; disallows decltype(auto) in trailing return type.<br>
<br>
</div>What makes you think that? That was not the intent and I cannot see<b=
r>
how to interpret the wording that way.<br>
<div class=3D""><div class=3D"h5"><br><br></div></div></blockquote><div><br=
></div><div>Me neither, the wording defines both auto and decltype(auto) to=
 be placeholder types, and<br>then allows both for trailing-return-type.<br=
>
<br>&quot;The auto <ins>and <tt>decltype(auto)</tt></ins> type-specifiers d=
esignate a placeholder type...&quot;<br><br>&quot;The <del>auto type-specif=
ier may</del>=20
<ins>placeholder type can</ins> appear with a
function declarator in the <i>decl-specifier-seq</i>,=20
<i>type-specifier-seq</i>, <i>conversion-function-id</i>,
or <i>trailing-return-type</i>...&quot;<br> </div></div><br></div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />
&nbsp;<br />
&nbsp;<br />

--20cf302d4e6046b2c704df718035--

.


Author: tomaszkam@gmail.com
Date: Tue, 18 Jun 2013 11:20:39 -0700 (PDT)
Raw View
------=_Part_777_27251913.1371579639948
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable

Sorry, that is may mistake, I has misinterpreted the statement:
Therefore, I propose to also allow decltype(auto) to get the decltype=20
semantics without having to repeat the expression. For simplicity of=20
specification and orthogonality I propose to allow it everywhere that plain=
=20
auto is allowed, except for introducing a *trailing-return-type*.
From "Difference from decltype" section.=20



W dniu wtorek, 18 czerwca 2013 20:01:23 UTC+2 u=BFytkownik Ville Voutilaine=
n=20
napisa=B3:
>
>
>
>
> On 18 June 2013 20:57, Richard Smith <ric...@metafoo.co.uk <javascript:>>=
wrote:
>
>> On Tue, Jun 18, 2013 at 10:54 AM,  <toma...@gmail.com <javascript:>>=20
>> wrote:
>> > The accepted N3638 Return type deduction for normal functions paper=20
>> allows
>> > auto return type in trailing return type for the usage in lambda, but
>> > disallows decltype(auto) in trailing return type.
>>
>> What makes you think that? That was not the intent and I cannot see
>> how to interpret the wording that way.
>>
>>
>>
> Me neither, the wording defines both auto and decltype(auto) to be=20
> placeholder types, and
> then allows both for trailing-return-type.
>
> "The auto and decltype(auto) type-specifiers designate a placeholder=20
> type..."
>
> "The auto type-specifier may placeholder type can appear with a function=
=20
> declarator in the *decl-specifier-seq*, *type-specifier-seq*, *
> conversion-function-id*, or *trailing-return-type*..."
>
>

--=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_777_27251913.1371579639948
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable

Sorry, that is may mistake, I has misinterpreted the statement:<br><span st=
yle=3D"font-family: courier new,monospace;">Therefore, I propose to also al=
low decltype(auto) to
get the decltype semantics without having to repeat the
expression.  For simplicity of specification and orthogonality I propose to
allow it everywhere that plain auto is allowed, except for
introducing a <i>trailing-return-type</i>.<br><font face=3D"arial,sans-seri=
f">From "</font></span>Difference from decltype" section. <br><br><br><br>W=
 dniu wtorek, 18 czerwca 2013 20:01:23 UTC+2 u=BFytkownik Ville Voutilainen=
 napisa=B3:<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"><b=
r><div><br><br><div class=3D"gmail_quote">On 18 June 2013 20:57, Richard Sm=
ith <span dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obf=
uscated-mailto=3D"m0-38dzNJIIJ">ric...@metafoo.co.uk</a>&gt;</span> wrote:<=
br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex"><div>On Tue, Jun 18, 2013=
 at 10:54 AM, &nbsp;&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfus=
cated-mailto=3D"m0-38dzNJIIJ">toma...@gmail.com</a>&gt; wrote:<br>

&gt; The accepted N3638 Return type deduction for normal functions paper al=
lows<br>
&gt; auto return type in trailing return type for the usage in lambda, but<=
br>
&gt; disallows decltype(auto) in trailing return type.<br>
<br>
</div>What makes you think that? That was not the intent and I cannot see<b=
r>
how to interpret the wording that way.<br>
<div><div><br><br></div></div></blockquote><div><br></div><div>Me neither, =
the wording defines both auto and decltype(auto) to be placeholder types, a=
nd<br>then allows both for trailing-return-type.<br>
<br>"The auto <ins>and <tt>decltype(auto)</tt></ins> type-specifiers design=
ate a placeholder type..."<br><br>"The <del>auto type-specifier may</del>=
=20
<ins>placeholder type can</ins> appear with a
function declarator in the <i>decl-specifier-seq</i>,=20
<i>type-specifier-seq</i>, <i>conversion-function-id</i>,
or <i>trailing-return-type</i>..."<br> </div></div><br></div></div>
</blockquote>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />
&nbsp;<br />
&nbsp;<br />

------=_Part_777_27251913.1371579639948--

.


Author: tomaszkam@gmail.com
Date: Tue, 18 Jun 2013 11:22:38 -0700 (PDT)
Raw View
------=_Part_832_19721562.1371579758045
Content-Type: text/plain; charset=ISO-8859-1

Sorry, that's my mistake, I misinterpreted the statement:
Therefore, I propose to also allow decltype(auto) to get the decltype
semantics without having to repeat the expression. For simplicity of
specification and orthogonality I propose to allow it everywhere that plain
auto is allowed, except for introducing a *trailing-return-type*.
From "Difference from decltype" section.

--

---
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_832_19721562.1371579758045
Content-Type: text/html; charset=ISO-8859-1

Sorry, that's my mistake, I misinterpreted the statement:<br><span style="font-family: courier new,monospace;">Therefore, I propose to also allow decltype(auto) to
get the decltype semantics without having to repeat the
expression.  For simplicity of specification and orthogonality I propose to
allow it everywhere that plain auto is allowed, except for
introducing a <i>trailing-return-type</i>.<br><font face="arial,sans-serif">From "</font></span>Difference from decltype" section. <br>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_832_19721562.1371579758045--

.


Author: Jonathan Wakely <cxx@kayari.org>
Date: Tue, 18 Jun 2013 11:28:40 -0700 (PDT)
Raw View
------=_Part_202_29434784.1371580120822
Content-Type: text/plain; charset=ISO-8859-1



On Tuesday, June 18, 2013 7:22:38 PM UTC+1, toma...@gmail.com wrote:
>
> Sorry, that's my mistake, I misinterpreted the statement:
> Therefore, I propose to also allow decltype(auto) to get the decltype
> semantics without having to repeat the expression. For simplicity of
> specification and orthogonality I propose to allow it everywhere that plain
> auto is allowed, except for introducing a *trailing-return-type*.
> From "Difference from decltype" section.
>

I believe that is saying this is not allowed:

decltype(auto) f() -> void { }



--

---
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_202_29434784.1371580120822
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br>On Tuesday, June 18, 2013 7:22:38 PM UTC+1, toma...@gmail.com wrote=
:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bo=
rder-left: 1px #ccc solid;padding-left: 1ex;">Sorry, that's my mistake, I m=
isinterpreted the statement:<br><span style=3D"font-family:courier new,mono=
space">Therefore, I propose to also allow decltype(auto) to
get the decltype semantics without having to repeat the
expression.  For simplicity of specification and orthogonality I propose to
allow it everywhere that plain auto is allowed, except for
introducing a <i>trailing-return-type</i>.<br><font face=3D"arial,sans-seri=
f">From "</font></span>Difference from decltype" section. <br></blockquote>=
<div><br></div><div>I believe that is saying this is not allowed:</div><div=
><br></div><div>decltype(auto) f() -&gt; void { }</div><div><br></div><div>=
&nbsp;</div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />
&nbsp;<br />
&nbsp;<br />

------=_Part_202_29434784.1371580120822--

.


Author: Zhihao Yuan <lichray@gmail.com>
Date: Wed, 19 Jun 2013 02:19:12 -0400
Raw View
On Tue, Jun 18, 2013 at 2:01 PM, Ville Voutilainen
<ville.voutilainen@gmail.com> wrote:
> "The auto and decltype(auto) type-specifiers designate a placeholder
> type..."

So the `decltype(auto)` as a whole is a placeholder.  It looks lengthy
to me.  It that OK to use just `decltype()` instead?

--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/

--

---
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: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Wed, 19 Jun 2013 10:05:36 +0300
Raw View
--20cf303b3aefe5a61d04df7c74a3
Content-Type: text/plain; charset=ISO-8859-1

On 19 June 2013 09:19, Zhihao Yuan <lichray@gmail.com> wrote:

> On Tue, Jun 18, 2013 at 2:01 PM, Ville Voutilainen
> <ville.voutilainen@gmail.com> wrote:
> > "The auto and decltype(auto) type-specifiers designate a placeholder
> > type..."
>
> So the `decltype(auto)` as a whole is a placeholder.  It looks lengthy
> to me.  It that OK to use just `decltype()` instead?
>
>
>
Not according to the current wording. Technically it would be possible, I
guess, as
decltype() is currently invalid, but I don't think it's as readable as
decltype(auto).

--

---
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/.



--20cf303b3aefe5a61d04df7c74a3
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 19 June 2013 09:19, Zhihao Yuan <span dir=3D"ltr">&lt;<a href=3D=
"mailto:lichray@gmail.com" target=3D"_blank">lichray@gmail.com</a>&gt;</spa=
n> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im">On Tue, Jun 18, 2013 at 2:=
01 PM, Ville Voutilainen<br>
&lt;<a href=3D"mailto:ville.voutilainen@gmail.com">ville.voutilainen@gmail.=
com</a>&gt; wrote:<br>
&gt; &quot;The auto and decltype(auto) type-specifiers designate a placehol=
der<br>
&gt; type...&quot;<br>
<br>
</div>So the `decltype(auto)` as a whole is a placeholder. =A0It looks leng=
thy<br>
to me. =A0It that OK to use just `decltype()` instead?<br>
<br><br></blockquote><div><br></div><div>Not according to the current wordi=
ng. Technically it would be possible, I guess, as<br>decltype() is currentl=
y invalid, but I don&#39;t think it&#39;s as readable as decltype(auto). <b=
r>
</div></div><br></div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />
&nbsp;<br />
&nbsp;<br />

--20cf303b3aefe5a61d04df7c74a3--

.


Author: Jonathan Wakely <cxx@kayari.org>
Date: Wed, 19 Jun 2013 02:27:57 -0700 (PDT)
Raw View
------=_Part_2477_1849378.1371634077501
Content-Type: text/plain; charset=ISO-8859-1



On Wednesday, June 19, 2013 8:05:36 AM UTC+1, Ville Voutilainen wrote:
>
>
>
>
> On 19 June 2013 09:19, Zhihao Yuan <lic...@gmail.com <javascript:>> wrote:
>
>> On Tue, Jun 18, 2013 at 2:01 PM, Ville Voutilainen
>> <ville.vo...@gmail.com <javascript:>> wrote:
>> > "The auto and decltype(auto) type-specifiers designate a placeholder
>> > type..."
>>
>> So the `decltype(auto)` as a whole is a placeholder.  It looks lengthy
>> to me.  It that OK to use just `decltype()` instead?
>>
>>
>>
> Not according to the current wording. Technically it would be possible, I
> guess, as
> decltype() is currently invalid, but I don't think it's as readable as
> decltype(auto).
>

Eurgh.

Surely decltype() with no expression should be the type returned by a
return statement with no expression, i.e. a void return.

So it would allow a new class of abomination:

    auto func(void) -> decltype() { }

 I feel quite ill.

--

---
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_2477_1849378.1371634077501
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br>On Wednesday, June 19, 2013 8:05:36 AM UTC+1, Ville Voutilainen wro=
te:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;=
border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><br><div><=
br><br><div class=3D"gmail_quote">On 19 June 2013 09:19, Zhihao Yuan <span =
dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-ma=
ilto=3D"l4NI2gcbT3EJ">lic...@gmail.com</a>&gt;</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 Tue, Jun 18, 2013 at 2:01 PM, Ville =
Voutilainen<br>
&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"l4NI=
2gcbT3EJ">ville.vo...@gmail.com</a>&gt; wrote:<br>
&gt; "The auto and decltype(auto) type-specifiers designate a placeholder<b=
r>
&gt; type..."<br>
<br>
</div>So the `decltype(auto)` as a whole is a placeholder. &nbsp;It looks l=
engthy<br>
to me. &nbsp;It that OK to use just `decltype()` instead?<br>
<br><br></blockquote><div><br></div><div>Not according to the current wordi=
ng. Technically it would be possible, I guess, as<br>decltype() is currentl=
y invalid, but I don't think it's as readable as decltype(auto). <br>
</div></div></div></div></blockquote><div><br>Eurgh.<br><br>Surely decltype=
() with no expression should be the type returned by a return statement wit=
h no expression, i.e. a void return.<br><br>So it would allow a new class o=
f abomination:<br><br>&nbsp;&nbsp;&nbsp; auto func(void) -&gt; decltype() {=
 }<br><br>&nbsp;I feel quite ill.<br><br></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />
&nbsp;<br />
&nbsp;<br />

------=_Part_2477_1849378.1371634077501--

.


Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Wed, 19 Jun 2013 13:47:13 +0300
Raw View
--001a11c2337a722ab504df7f8d14
Content-Type: text/plain; charset=ISO-8859-1

On 19 June 2013 12:27, Jonathan Wakely <cxx@kayari.org> wrote:

> Eurgh.
>
> Surely decltype() with no expression should be the type returned by a
> return statement with no expression, i.e. a void return.
>

Failing to comprehend british sarcasm, that's not currently the case.


>
> So it would allow a new class of abomination:
>
>     auto func(void) -> decltype() { }
>
>  I feel quite ill.
>
>
I guess one man's abomination is another man's pinnacle of beauty. However,
I have no desire to
support this decltype(), whether an abomination or non-abomination. I
prefer sticking to decltype(auto)
as it is.

--

---
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/.



--001a11c2337a722ab504df7f8d14
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 19 June 2013 12:27, Jonathan Wakely <span dir=3D"ltr">&lt;<a hre=
f=3D"mailto:cxx@kayari.org" target=3D"_blank">cxx@kayari.org</a>&gt;</span>=
 wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">Eurgh.<br><div><br>Surely decltype() with no=
 expression should be the type returned by a return statement with no expre=
ssion, i.e. a void return.<br>
</div></blockquote><div><br></div><div>Failing to comprehend british sarcas=
m, that&#39;s not currently the case.<br>=A0<br></div><blockquote class=3D"=
gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-=
left:1ex">
<div><br>So it would allow a new class of abomination:<br><br>=A0=A0=A0 aut=
o func(void) -&gt; decltype() { }<br><br>=A0I feel quite ill.<br><br></div>=
</blockquote><div><br></div><div>I guess one man&#39;s abomination is anoth=
er man&#39;s pinnacle of beauty. However, I have no desire to<br>
support this decltype(), whether an abomination or non-abomination. I prefe=
r sticking to decltype(auto)<br>as it is. <br></div></div><br></div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />
&nbsp;<br />
&nbsp;<br />

--001a11c2337a722ab504df7f8d14--

.


Author: Jonathan Wakely <cxx@kayari.org>
Date: Wed, 19 Jun 2013 03:52:39 -0700 (PDT)
Raw View
------=_Part_446_8010092.1371639159292
Content-Type: text/plain; charset=ISO-8859-1



On Wednesday, June 19, 2013 11:47:13 AM UTC+1, Ville Voutilainen wrote:
>
>
>
>
> On 19 June 2013 12:27, Jonathan Wakely <c...@kayari.org <javascript:>>wrote:
>
>> Eurgh.
>>
>> Surely decltype() with no expression should be the type returned by a
>> return statement with no expression, i.e. a void return.
>>
>
> Failing to comprehend british sarcasm, that's not currently the case.
>
>
>>
>> So it would allow a new class of abomination:
>>
>>     auto func(void) -> decltype() { }
>>
>>  I feel quite ill.
>>
>>
> I guess one man's abomination is another man's pinnacle of beauty.
> However, I have no desire to
> support this decltype(), whether an abomination or non-abomination. I
> prefer sticking to decltype(auto)
> as it is.
>

Agreed.


--

---
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_446_8010092.1371639159292
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br>On Wednesday, June 19, 2013 11:47:13 AM UTC+1, Ville Voutilainen wr=
ote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex=
;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><br><div>=
<br><br><div class=3D"gmail_quote">On 19 June 2013 12:27, Jonathan Wakely <=
span dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscat=
ed-mailto=3D"Z1ThjNVDwL4J">c...@kayari.org</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">Eurgh.<br><div><br>Surely decltype() with no=
 expression should be the type returned by a return statement with no expre=
ssion, i.e. a void return.<br>
</div></blockquote><div><br></div><div>Failing to comprehend british sarcas=
m, that's not currently the case.<br>&nbsp;<br></div><blockquote class=3D"g=
mail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-l=
eft:1ex">
<div><br>So it would allow a new class of abomination:<br><br>&nbsp;&nbsp;&=
nbsp; auto func(void) -&gt; decltype() { }<br><br>&nbsp;I feel quite ill.<b=
r><br></div></blockquote><div><br></div><div>I guess one man's abomination =
is another man's pinnacle of beauty. However, I have no desire to<br>
support this decltype(), whether an abomination or non-abomination. I prefe=
r sticking to decltype(auto)<br>as it is. <br></div></div></div></div></blo=
ckquote><div><br>Agreed.<br>&nbsp;</div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />
&nbsp;<br />
&nbsp;<br />

------=_Part_446_8010092.1371639159292--

.


Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Wed, 19 Jun 2013 14:10:44 +0300
Raw View
--20cf3074d67688503304df7fe128
Content-Type: text/plain; charset=ISO-8859-1

On 19 June 2013 13:52, Jonathan Wakely <cxx@kayari.org> wrote:

>
> I guess one man's abomination is another man's pinnacle of beauty.
>> However, I have no desire to
>> support this decltype(), whether an abomination or non-abomination. I
>> prefer sticking to decltype(auto)
>> as it is.
>>
>
> Agreed.
>
>
For the uninitiated, be aware that this is a conspiracy. The only thing
Jonathan and I have thus far managed
to disagree on is what he should work on next, regarding libstdc++. On
everything else, we have managed
to agree with a frightening percentage. :)

--

---
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/.



--20cf3074d67688503304df7fe128
Content-Type: text/html; charset=ISO-8859-1

<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On 19 June 2013 13:52, Jonathan Wakely <span dir="ltr">&lt;<a href="mailto:cxx@kayari.org" target="_blank">cxx@kayari.org</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br><div><div class="h5"><blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div><div class="gmail_quote"><div>I guess one man&#39;s abomination is another man&#39;s pinnacle of beauty. However, I have no desire to<br>
support this decltype(), whether an abomination or non-abomination. I prefer sticking to decltype(auto)<br>as it is. <br></div></div></div></div></blockquote></div></div><div><br>Agreed.<br><br></div></blockquote><div><br>
</div><div>For the uninitiated, be aware that this is a conspiracy. The only thing Jonathan and I have thus far managed<br></div><div>to disagree on is what he should work on next, regarding libstdc++. On everything else, we have managed<br>
</div><div>to agree with a frightening percentage. :) <br></div></div><br></div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br />
&nbsp;<br />
&nbsp;<br />

--20cf3074d67688503304df7fe128--

.


Author: Jonathan Wakely <cxx@kayari.org>
Date: Wed, 19 Jun 2013 04:36:19 -0700 (PDT)
Raw View
------=_Part_652_304909.1371641779637
Content-Type: text/plain; charset=ISO-8859-1



On Wednesday, June 19, 2013 12:10:44 PM UTC+1, Ville Voutilainen wrote:
>
>
>
>
> On 19 June 2013 13:52, Jonathan Wakely <c...@kayari.org <javascript:>>wrote:
>
>>
>> I guess one man's abomination is another man's pinnacle of beauty.
>>> However, I have no desire to
>>> support this decltype(), whether an abomination or non-abomination. I
>>> prefer sticking to decltype(auto)
>>> as it is.
>>>
>>
>> Agreed.
>>
>>
> For the uninitiated, be aware that this is a conspiracy. The only thing
> Jonathan and I have thus far managed
> to disagree on is what he should work on next, regarding libstdc++. On
> everything else, we have managed
> to agree with a frightening percentage. :)
>

Where's the upvote button?  ;-)


We disagreed on LWG 2051, but I think you might have persuaded me ... you
at least managed to confuse me because I can't even remember my own opinion
now.

--

---
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_652_304909.1371641779637
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br>On Wednesday, June 19, 2013 12:10:44 PM UTC+1, Ville Voutilainen wr=
ote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex=
;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><br><div>=
<br><br><div class=3D"gmail_quote">On 19 June 2013 13:52, Jonathan Wakely <=
span dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscat=
ed-mailto=3D"zdZ3zrrpEjEJ">c...@kayari.org</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><br><div><div><blockquote class=3D"gmail_quo=
te" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-=
left:1ex">
<div dir=3D"ltr"><div><div class=3D"gmail_quote"><div>I guess one man's abo=
mination is another man's pinnacle of beauty. However, I have no desire to<=
br>
support this decltype(), whether an abomination or non-abomination. I prefe=
r sticking to decltype(auto)<br>as it is. <br></div></div></div></div></blo=
ckquote></div></div><div><br>Agreed.<br><br></div></blockquote><div><br>
</div><div>For the uninitiated, be aware that this is a conspiracy. The onl=
y thing Jonathan and I have thus far managed<br></div><div>to disagree on i=
s what he should work on next, regarding libstdc++. On everything else, we =
have managed<br>
</div><div>to agree with a frightening percentage. :) <br></div></div></div=
></div></blockquote><div><br>Where's the upvote button?&nbsp; ;-)<br><br><b=
r>We disagreed on LWG 2051, but I think you might have persuaded me ... you=
 at least managed to confuse me because I can't even remember my own opinio=
n now.<br></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />
&nbsp;<br />
&nbsp;<br />

------=_Part_652_304909.1371641779637--

.


Author: Nicol Bolas <jmckesson@gmail.com>
Date: Wed, 19 Jun 2013 08:10:57 -0700 (PDT)
Raw View
------=_Part_104_31015326.1371654657774
Content-Type: text/plain; charset=ISO-8859-1

On Wednesday, June 19, 2013 2:27:57 AM UTC-7, Jonathan Wakely wrote:
>
> On Wednesday, June 19, 2013 8:05:36 AM UTC+1, Ville Voutilainen wrote:
>>
>> On 19 June 2013 09:19, Zhihao Yuan <lic...@gmail.com> wrote:
>>
>>> On Tue, Jun 18, 2013 at 2:01 PM, Ville Voutilainen
>>> <ville.vo...@gmail.com> wrote:
>>> > "The auto and decltype(auto) type-specifiers designate a placeholder
>>> > type..."
>>>
>>> So the `decltype(auto)` as a whole is a placeholder.  It looks lengthy
>>> to me.  It that OK to use just `decltype()` instead?
>>>
>>>
>>>
>> Not according to the current wording. Technically it would be possible, I
>> guess, as
>> decltype() is currently invalid, but I don't think it's as readable as
>> decltype(auto).
>>
>
> Eurgh.
>
> Surely decltype() with no expression should be the type returned by a
> return statement with no expression, i.e. a void return.
>
> So it would allow a new class of abomination:
>
>     auto func(void) -> decltype() { }
>
>  I feel quite ill.
>
>
Why would you use late-specified return values on a regular function
that... does type deduction? You would use:

decltype(auto) func(void);

The only reason to use late-specified return types with decltype-deduction
is in a lambda function where you *can't* use early-specified return types.
In which case it's just:

[](...) ->decltype(auto) {}

And furthermore, decltype(auto) will (likely) be the *exception*, not the
rule.  So you won't even see it that much.

--

---
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_104_31015326.1371654657774
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Wednesday, June 19, 2013 2:27:57 AM UTC-7, Jonathan Wakely wrote:<blockq=
uote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-lef=
t: 1px #ccc solid;padding-left: 1ex;">On Wednesday, June 19, 2013 8:05:36 A=
M UTC+1, Ville Voutilainen wrote:<blockquote class=3D"gmail_quote" style=3D=
"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><d=
iv dir=3D"ltr"><div><div class=3D"gmail_quote">On 19 June 2013 09:19, Zhiha=
o Yuan <span dir=3D"ltr">&lt;<a>lic...@gmail.com</a>&gt;</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 Tue, Jun 18, 2013 at 2:01 PM, Ville =
Voutilainen<br>
&lt;<a>ville.vo...@gmail.com</a>&gt; wrote:<br>
&gt; "The auto and decltype(auto) type-specifiers designate a placeholder<b=
r>
&gt; type..."<br>
<br>
</div>So the `decltype(auto)` as a whole is a placeholder. &nbsp;It looks l=
engthy<br>
to me. &nbsp;It that OK to use just `decltype()` instead?<br>
<br><br></blockquote><div><br></div><div>Not according to the current wordi=
ng. Technically it would be possible, I guess, as<br>decltype() is currentl=
y invalid, but I don't think it's as readable as decltype(auto). <br>
</div></div></div></div></blockquote><div><br>Eurgh.<br><br>Surely decltype=
() with no expression should be the type returned by a return statement wit=
h no expression, i.e. a void return.<br><br>So it would allow a new class o=
f abomination:<br><br>&nbsp;&nbsp;&nbsp; auto func(void) -&gt; decltype() {=
 }<br><br>&nbsp;I feel quite ill.<br><br></div></blockquote><div><br>Why wo=
uld you use late-specified return values on a regular function that... does=
 type deduction? You would use:<br><br><div class=3D"prettyprint" style=3D"=
background-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); bor=
der-style: solid; border-width: 1px; word-wrap: break-word;"><code class=3D=
"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #008;" cl=
ass=3D"styled-by-prettify">decltype</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">(</span><span style=3D"color: #008;" class=3D"styl=
ed-by-prettify">auto</span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">)</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> func</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</s=
pan><span style=3D"color: #008;" class=3D"styled-by-prettify">void</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">);</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"><br></span></div></code></d=
iv><br>The only reason to use late-specified return types with decltype-ded=
uction is in a lambda function where you <i>can't</i> use early-specified r=
eturn types. In which case it's just:<br><br><div class=3D"prettyprint" sty=
le=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187=
); border-style: solid; border-width: 1px; word-wrap: break-word;"><code cl=
ass=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">[](...)</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">-&gt;</span><span style=3D"color: #008;" class=3D"styl=
ed-by-prettify">decltype</span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">(</span><span style=3D"color: #008;" class=3D"styled-by-prett=
ify">auto</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: #660;" class=3D"styled-by-prettify">{}</span></div></co=
de></div><br>And furthermore, decltype(auto) will (likely) be the <i>except=
ion</i>, not the rule.&nbsp; So you won't even see it that much.<br></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />
&nbsp;<br />
&nbsp;<br />

------=_Part_104_31015326.1371654657774--

.


Author: Zhihao Yuan <lichray@gmail.com>
Date: Wed, 19 Jun 2013 11:20:19 -0400
Raw View
On Wed, Jun 19, 2013 at 11:10 AM, Nicol Bolas <jmckesson@gmail.com> wrote:
> [](...) ->decltype(auto) {}
>
> And furthermore, decltype(auto) will (likely) be the exception, not the
> rule.  So you won't even see it that much.

Yea, I know, to functions the main purpose is to explain the return
type deduction.  However, I found that

  decltype(auto) v = expr;

may become popular, so I'm wondering whether it worth a better syntax.

--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/

--

---
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: Jonathan Wakely <cxx@kayari.org>
Date: Wed, 19 Jun 2013 08:23:00 -0700 (PDT)
Raw View
------=_Part_1538_29268761.1371655380892
Content-Type: text/plain; charset=ISO-8859-1



On Wednesday, June 19, 2013 4:10:57 PM UTC+1, Nicol Bolas wrote:
>
> On Wednesday, June 19, 2013 2:27:57 AM UTC-7, Jonathan Wakely wrote:
>>
>> On Wednesday, June 19, 2013 8:05:36 AM UTC+1, Ville Voutilainen wrote:
>>>
>>> On 19 June 2013 09:19, Zhihao Yuan <lic...@gmail.com> wrote:
>>>
>>>> On Tue, Jun 18, 2013 at 2:01 PM, Ville Voutilainen
>>>> <ville.vo...@gmail.com> wrote:
>>>> > "The auto and decltype(auto) type-specifiers designate a placeholder
>>>> > type..."
>>>>
>>>> So the `decltype(auto)` as a whole is a placeholder.  It looks lengthy
>>>> to me.  It that OK to use just `decltype()` instead?
>>>>
>>>>
>>>>
>>> Not according to the current wording. Technically it would be possible,
>>> I guess, as
>>> decltype() is currently invalid, but I don't think it's as readable as
>>> decltype(auto).
>>>
>>
>> Eurgh.
>>
>> Surely decltype() with no expression should be the type returned by a
>> return statement with no expression, i.e. a void return.
>>
>> So it would allow a new class of abomination:
>>
>>     auto func(void) -> decltype() { }
>>
>>  I feel quite ill.
>>
>>
> Why would you use late-specified return values on a regular function
> that... does type deduction?
>

You wouldn't. Did you miss the part where I called it an abomination and
said I feel ill?

--

---
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_1538_29268761.1371655380892
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br>On Wednesday, June 19, 2013 4:10:57 PM UTC+1, Nicol Bolas wrote:<bl=
ockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border=
-left: 1px #ccc solid;padding-left: 1ex;">On Wednesday, June 19, 2013 2:27:=
57 AM UTC-7, Jonathan Wakely wrote:<blockquote class=3D"gmail_quote" style=
=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"=
>On Wednesday, June 19, 2013 8:05:36 AM UTC+1, Ville Voutilainen wrote:<blo=
ckquote 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 class=3D"gma=
il_quote">On 19 June 2013 09:19, Zhihao Yuan <span dir=3D"ltr">&lt;<a>lic..=
..@gmail.com</a>&gt;</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 Tue, Jun 18, 2013 at 2:01 PM, Ville =
Voutilainen<br>
&lt;<a>ville.vo...@gmail.com</a>&gt; wrote:<br>
&gt; "The auto and decltype(auto) type-specifiers designate a placeholder<b=
r>
&gt; type..."<br>
<br>
</div>So the `decltype(auto)` as a whole is a placeholder. &nbsp;It looks l=
engthy<br>
to me. &nbsp;It that OK to use just `decltype()` instead?<br>
<br><br></blockquote><div><br></div><div>Not according to the current wordi=
ng. Technically it would be possible, I guess, as<br>decltype() is currentl=
y invalid, but I don't think it's as readable as decltype(auto). <br>
</div></div></div></div></blockquote><div><br>Eurgh.<br><br>Surely decltype=
() with no expression should be the type returned by a return statement wit=
h no expression, i.e. a void return.<br><br>So it would allow a new class o=
f abomination:<br><br>&nbsp;&nbsp;&nbsp; auto func(void) -&gt; decltype() {=
 }<br><br>&nbsp;I feel quite ill.<br><br></div></blockquote><div><br>Why wo=
uld you use late-specified return values on a regular function that... does=
 type deduction? </div></blockquote><div><br>You wouldn't. Did you miss the=
 part where I called it an abomination and said I feel ill?</div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />
&nbsp;<br />
&nbsp;<br />

------=_Part_1538_29268761.1371655380892--

.


Author: Jonathan Wakely <cxx@kayari.org>
Date: Wed, 19 Jun 2013 08:27:35 -0700 (PDT)
Raw View
------=_Part_132_21402837.1371655655227
Content-Type: text/plain; charset=ISO-8859-1



On Wednesday, June 19, 2013 4:23:00 PM UTC+1, Jonathan Wakely wrote:
>
>
>
> On Wednesday, June 19, 2013 4:10:57 PM UTC+1, Nicol Bolas wrote:
>>
>> On Wednesday, June 19, 2013 2:27:57 AM UTC-7, Jonathan Wakely wrote:
>>>
>>> On Wednesday, June 19, 2013 8:05:36 AM UTC+1, Ville Voutilainen wrote:
>>>>
>>>> On 19 June 2013 09:19, Zhihao Yuan <lic...@gmail.com> wrote:
>>>>
>>>>> On Tue, Jun 18, 2013 at 2:01 PM, Ville Voutilainen
>>>>> <ville.vo...@gmail.com> wrote:
>>>>> > "The auto and decltype(auto) type-specifiers designate a placeholder
>>>>> > type..."
>>>>>
>>>>> So the `decltype(auto)` as a whole is a placeholder.  It looks lengthy
>>>>> to me.  It that OK to use just `decltype()` instead?
>>>>>
>>>>>
>>>>>
>>>> Not according to the current wording. Technically it would be possible,
>>>> I guess, as
>>>> decltype() is currently invalid, but I don't think it's as readable as
>>>> decltype(auto).
>>>>
>>>
>>> Eurgh.
>>>
>>> Surely decltype() with no expression should be the type returned by a
>>> return statement with no expression, i.e. a void return.
>>>
>>> So it would allow a new class of abomination:
>>>
>>>     auto func(void) -> decltype() { }
>>>
>>>  I feel quite ill.
>>>
>>>
>> Why would you use late-specified return values on a regular function
>> that... does type deduction?
>>
>
> You wouldn't. Did you miss the part where I called it an abomination and
> said I feel ill?
>

If you want to pick holes in it, why would you write (void) in a function
using a trailing-return-type, when the only purpose of (void) is C
interoperability and a trailing-return-type isn't valid in C?


--

---
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_132_21402837.1371655655227
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br>On Wednesday, June 19, 2013 4:23:00 PM UTC+1, Jonathan Wakely wrote=
:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bo=
rder-left: 1px #ccc solid;padding-left: 1ex;"><br><br>On Wednesday, June 19=
, 2013 4:10:57 PM UTC+1, Nicol Bolas wrote:<blockquote class=3D"gmail_quote=
" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-le=
ft:1ex">On Wednesday, June 19, 2013 2:27:57 AM UTC-7, Jonathan Wakely wrote=
:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bord=
er-left:1px #ccc solid;padding-left:1ex">On Wednesday, June 19, 2013 8:05:3=
6 AM UTC+1, Ville Voutilainen wrote:<blockquote class=3D"gmail_quote" style=
=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"=
><div dir=3D"ltr"><div><div class=3D"gmail_quote">On 19 June 2013 09:19, Zh=
ihao Yuan <span dir=3D"ltr">&lt;<a>lic...@gmail.com</a>&gt;</span> wrote:<b=
r>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div>On Tue, Jun 18, 2013 at 2:01 PM, Ville =
Voutilainen<br>
&lt;<a>ville.vo...@gmail.com</a>&gt; wrote:<br>
&gt; "The auto and decltype(auto) type-specifiers designate a placeholder<b=
r>
&gt; type..."<br>
<br>
</div>So the `decltype(auto)` as a whole is a placeholder. &nbsp;It looks l=
engthy<br>
to me. &nbsp;It that OK to use just `decltype()` instead?<br>
<br><br></blockquote><div><br></div><div>Not according to the current wordi=
ng. Technically it would be possible, I guess, as<br>decltype() is currentl=
y invalid, but I don't think it's as readable as decltype(auto). <br>
</div></div></div></div></blockquote><div><br>Eurgh.<br><br>Surely decltype=
() with no expression should be the type returned by a return statement wit=
h no expression, i.e. a void return.<br><br>So it would allow a new class o=
f abomination:<br><br>&nbsp;&nbsp;&nbsp; auto func(void) -&gt; decltype() {=
 }<br><br>&nbsp;I feel quite ill.<br><br></div></blockquote><div><br>Why wo=
uld you use late-specified return values on a regular function that... does=
 type deduction? </div></blockquote><div><br>You wouldn't. Did you miss the=
 part where I called it an abomination and said I feel ill?</div></blockquo=
te><div><br>If you want to pick holes in it, why would you write (void) in =
a function using a trailing-return-type, when the only purpose of (void) is=
 C interoperability and a trailing-return-type isn't valid in C?<br><br><br=
></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />
&nbsp;<br />
&nbsp;<br />

------=_Part_132_21402837.1371655655227--

.