--e89a8fb1fe369c2d5704e5a005af
Content-Type: text/plain; charset=ISO-8859-1

On 5 September 2013 12:33, Nicol Bolas <jmckesson@gmail.com> wrote:

> On Wednesday, September 4, 2013 7:30:01 PM UTC-7, jgot...@gmail.com wrote:
>>
>> Paper N3748 (Implicit Evaluation of auto Variables and Arguments<https://groups.google.com/a/isocpp.org/forum/?fromgroups#!newtopic/std-proposals>)
>> proposes an "operator auto" to handle the problems that auto has with
>> expression templates and similar classes.  If a class Foo defines a member
>> function operator auto() returning type Bar, then in the code
>>
>> Foo foo;
>> auto x = foo;
>>
>> the type of x would be Bar and not Foo.  While I think this a good idea,
>> I think that there are some items that are missing:
>>
>> 1) How does this interact with the C++14 decltype(auto) construct?  I
>> would expect the code
>> decltype(auto) y = foo;
>>
>> to actually declare an object of type Foo, despite the existence of the
>> operator auto() function.  The paper currently uses "explicit auto" to
>> disable operator auto, but using decltype(auto) for this would fit in
>> better with existing rules.
>>
>
> That's... problematic. `decltype(auto)` has a very different set of type
> deduction rules for expressions than `auto`. I wouldn't want to have to be
> forced into the `decltype(auto)` syntax just to get a variable of the
> actual expression's type.
>
> That being said, `decltype(auto)` very much should deduce the actual type.
> It just shouldn't be the *only* way to do so.
>

I don't know how you come to such conclusions. The purpose of
decltype(auto) is not deducing an "actual type"
in this sense. I would expect decltype(auto) y = foo; to invoke an operator
auto of foo's type, if any, and needing
to use explicit decltype(auto) y = foo; if I don't want operator auto to be
invoked.


>
>
>> 2)  How does this interact with return-type deduction in lambdas and
>> normal functions?  If you have a function
>>
>> auto myFunc() -> auto {Foo foo; return foo;}
>>
>> is the return type of myFunc() Foo or Bar?
>>
>
> First, I'm fairly sure you don't need two autos there; I think that may be
> a compile error in C++14.
>
> As for the question, that will be dealt when as they clear up the
> consistency issue brought up in the paper.
>

I would expect the return type is Bar.


> 3) Would it be possible to overload operator auto() on the constness or
>> rvalue-ness of *this?  Something like
>>
>> Bar operator auto() const & {return Bar(*this);} // copy lvalues
>> Bar operator auto() && {return Bar(move(*this)); } // move rvalues
>>
>>
> I see no reason why that shouldn't or couldn't be allowed. Though if it is
> allowed, I would much rather the `= default` syntax to automatically
> generate *both*.
>
>
>
>
I expect an operator auto to allow the same ref-qualifiers as any other
conversion operator, so I think this should
be allowed. Generating both seems reasonable, but we do need to be careful
about whether the generated
operators end up deleted (or suppressed).

--

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

--e89a8fb1fe369c2d5704e5a005af
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 5 September 2013 12:33, Nicol Bolas <span dir=3D"ltr">&lt;<a hre=
f=3D"mailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@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 dir=3D"ltr"><div class=3D"im">On Wednes=
day, September 4, 2013 7:30:01 PM UTC-7, <a href=3D"mailto:jgot...@gmail.co=
m" target=3D"_blank">jgot...@gmail.com</a> wrote:<blockquote class=3D"gmail=
_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">
<div dir=3D"ltr">Paper N3748 (<a href=3D"https://groups.google.com/a/isocpp=
..org/forum/?fromgroups#!newtopic/std-proposals" target=3D"_blank">Implicit =
Evaluation of auto Variables and Arguments</a>) proposes an &quot;operator =
auto&quot; to handle the problems that auto has with expression templates a=
nd similar classes.=A0 If a class Foo defines a member function operator au=
to() returning type Bar, then in the code<br>
<br><div style=3D"background-color:rgb(250,250,250);border-color:rgb(187,18=
7,187);border-style:solid;border-width:1px;word-wrap:break-word"><code><div=
><span style=3D"color:#606">Foo</span><span style> foo</span><span style=3D=
"color:#660">;</span><span style><br>
</span><span style=3D"color:#008">auto</span><span style> x </span><span st=
yle=3D"color:#660">=3D</span><span style> foo</span><span style=3D"color:#6=
60">;</span><span style><br></span></div></code></div><br>the type of x wou=
ld be Bar and not Foo.=A0 While I think this a good idea, I think that ther=
e are some items that are missing:<br>
<br>1) How does this interact with the C++14 decltype(auto) construct?=A0 I=
 would expect the code<br><div style=3D"background-color:rgb(250,250,250);b=
order-color:rgb(187,187,187);border-style:solid;border-width:1px;word-wrap:=
break-word">
<code><div><span style=3D"color:#008">decltype</span><span style=3D"color:#=
660">(</span><span style=3D"color:#008">auto</span><span style=3D"color:#66=
0">)</span><span style> y </span><span style=3D"color:#660">=3D</span><span=
 style> foo</span><span style=3D"color:#660">;</span><span style><br>
</span></div></code></div><br>to actually declare an object of type Foo, de=
spite the existence of the operator auto() function.=A0 The paper currently=
 uses &quot;explicit auto&quot; to disable operator auto, but using decltyp=
e(auto) for this would fit in better with existing rules.<br>
</div></blockquote></div><div><br>That&#39;s... problematic. `decltype(auto=
)` has a very different set of type deduction rules for expressions than `a=
uto`. I wouldn&#39;t want to have to be forced into the `decltype(auto)` sy=
ntax just to get a variable of the actual expression&#39;s type.<br>
<br>That being said, `decltype(auto)` very much should deduce the actual ty=
pe. It just shouldn&#39;t be the <i>only</i> way to do so.<br></div></div><=
/blockquote><div><br></div><div>I don&#39;t know how you come to such concl=
usions. The purpose of decltype(auto) is not deducing an &quot;actual type&=
quot;<br>
in this sense. I would expect decltype(auto) y =3D foo; to invoke an operat=
or auto of foo&#39;s type, if any, and needing<br>to use explicit decltype(=
auto) y =3D foo; if I don&#39;t want operator auto to be invoked.<br>=A0<br=
></div>
<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"><div>=A0</div><div class=3D=
"im"><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">2)=A0 How does this interact with return-type deduction in=
 lambdas and normal functions?=A0 If you have a function<br><br><div style=
=3D"background-color:rgb(250,250,250);border-color:rgb(187,187,187);border-=
style:solid;border-width:1px;word-wrap:break-word">
<code><div><span style=3D"color:#008">auto</span><span style> myFunc</span>=
<span style=3D"color:#660">()</span><span style> </span><span style=3D"colo=
r:#660">-&gt;</span><span style> </span><span style=3D"color:#008">auto</sp=
an><span style> </span><span style=3D"color:#660">{</span><span style=3D"co=
lor:#606">Foo</span><span style> foo</span><span style=3D"color:#660">;</sp=
an><span style> </span><span style=3D"color:#008">return</span><span style>=
 foo</span><span style=3D"color:#660">;}</span><span style><br>
</span></div></code></div><br>is the return type of myFunc() Foo or Bar?<br=
></div></blockquote></div><div><br>First, I&#39;m fairly sure you don&#39;t=
 need two autos there; I think that may be a compile error in C++14.<br>
<br>As for the question, that will be dealt when as they clear up the consi=
stency issue brought up in the paper.<br></div></div></blockquote><div><br>=
</div><div>I would expect the return type is Bar.<br>=A0<br></div><blockquo=
te class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc so=
lid;padding-left:1ex">
<div dir=3D"ltr"><div class=3D"im"><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">3) Would it be possible to overload operator auto() on th=
e constness or rvalue-ness of *this?=A0 Something like<br>
<br><div style=3D"background-color:rgb(250,250,250);border-color:rgb(187,18=
7,187);border-style:solid;border-width:1px;word-wrap:break-word"><code><div=
><span style=3D"color:#606">Bar</span><span style> </span><span style=3D"co=
lor:#008">operator</span><span style> </span><span style=3D"color:#008">aut=
o</span><span style=3D"color:#660">()</span><span style> </span><span style=
=3D"color:#008">const</span><span style> </span><span style=3D"color:#660">=
&amp;</span><span style> </span><span style=3D"color:#660">{</span><span st=
yle=3D"color:#008">return</span><span style> </span><span style=3D"color:#6=
06">Bar</span><span style=3D"color:#660">(*</span><span style=3D"color:#008=
">this</span><span style=3D"color:#660">);}</span><span style> </span><span=
 style=3D"color:#800">// copy lvalues</span><span style><br>
</span><span style=3D"color:#606">Bar</span><span style> </span><span style=
=3D"color:#008">operator</span><span style> </span><span style=3D"color:#00=
8">auto</span><span style=3D"color:#660">()</span><span style> </span><span=
 style=3D"color:#660">&amp;&amp;</span><span style> </span><span style=3D"c=
olor:#660">{</span><span style=3D"color:#008">return</span><span style> </s=
pan><span style=3D"color:#606">Bar</span><span style=3D"color:#660">(</span=
><span style>move</span><span style=3D"color:#660">(*</span><span style=3D"=
color:#008">this</span><span style=3D"color:#660">));</span><span style> </=
span><span style=3D"color:#660">}</span><span style> </span><span style=3D"=
color:#800">// move rvalues</span><span style><br>
</span></div></code></div><br></div></blockquote></div><div><br>I see no re=
ason why that shouldn&#39;t or couldn&#39;t be allowed. Though if it is all=
owed, I would much rather the `=3D default` syntax to automatically generat=
e <i>both</i>.<br>
</div></div><div class=3D"HOEnZb"><div class=3D"h5">

<p></p>

<br><br></div></div></blockquote><div><br></div><div>I expect an operator a=
uto to allow the same ref-qualifiers as any other conversion operator, so I=
 think this should<br>be allowed. Generating both seems reasonable, but we =
do need to be careful about whether the generated<br>
</div><div>operators end up deleted (or suppressed).<br></div></div><br></d=
iv></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 />

--e89a8fb1fe369c2d5704e5a005af--

.

------=_Part_2505_8844788.1378377656359
Content-Type: text/plain; charset=ISO-8859-1



On Thursday, September 5, 2013 3:02:38 AM UTC-7, Ville Voutilainen wrote:
>
>
>
>
> On 5 September 2013 12:33, Nicol Bolas <jmck...@gmail.com <javascript:>>wrote:
>
>> On Wednesday, September 4, 2013 7:30:01 PM UTC-7, jgot...@gmail.comwrote:
>>>
>>> Paper N3748 (Implicit Evaluation of auto Variables and Arguments<https://groups.google.com/a/isocpp.org/forum/?fromgroups#!newtopic/std-proposals>)
>>> proposes an "operator auto" to handle the problems that auto has with
>>> expression templates and similar classes.  If a class Foo defines a member
>>> function operator auto() returning type Bar, then in the code
>>>
>>> Foo foo;
>>> auto x = foo;
>>>
>>> the type of x would be Bar and not Foo.  While I think this a good idea,
>>> I think that there are some items that are missing:
>>>
>>> 1) How does this interact with the C++14 decltype(auto) construct?  I
>>> would expect the code
>>> decltype(auto) y = foo;
>>>
>>> to actually declare an object of type Foo, despite the existence of the
>>> operator auto() function.  The paper currently uses "explicit auto" to
>>> disable operator auto, but using decltype(auto) for this would fit in
>>> better with existing rules.
>>>
>>
>> That's... problematic. `decltype(auto)` has a very different set of type
>> deduction rules for expressions than `auto`. I wouldn't want to have to be
>> forced into the `decltype(auto)` syntax just to get a variable of the
>> actual expression's type.
>>
>> That being said, `decltype(auto)` very much should deduce the actual
>> type. It just shouldn't be the *only* way to do so.
>>
>
> I don't know how you come to such conclusions. The purpose of
> decltype(auto) is not deducing an "actual type"
> in this sense. I would expect decltype(auto) y = foo; to invoke an
> operator auto of foo's type, if any, and needing
> to use explicit decltype(auto) y = foo; if I don't want operator auto to
> be invoked.
>

The thing is, the rules for `auto` type deduction, template type deduction,
and so forth are all the same (minus one caveat). The rules for `decltype`
type deduction are *different* from them. Since it already has differences
in the way it deduces the type of an expression, there's no specific
expectation or requirement that `decltype(auto) y = foo;` to deduce the
same type as `auto y = foo;`. Indeed, if you *wanted* the same type
deduction, you wouldn't have used `decltype(auto)` at all.

Decltype deduction is different from regular type deduction for a reason.

I'm not saying that it *couldn't* work. I'm saying that it shouldn't work
just because; that there needs to be some specific reason why users would
expect it to work. Remember: the only people who would use `decltype(auto)`
are those who know what that is and know their type deduction rules well
enough to know that they need that in this scenario. And those people
probably don't *want* the deduction to use `operator 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/.

------=_Part_2505_8844788.1378377656359
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Thursday, September 5, 2013 3:02:38 AM UTC-7, V=
ille Voutilainen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0=
;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div di=
r=3D"ltr"><br><div><br><br><div class=3D"gmail_quote">On 5 September 2013 1=
2:33, Nicol Bolas <span dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_=
blank" gdf-obfuscated-mailto=3D"bwloaBhpDXQJ">jmck...@gmail.com</a>&gt;</sp=
an> 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"><div>On Wednesday, Septembe=
r 4, 2013 7:30:01 PM UTC-7, <a>jgot...@gmail.com</a> wrote:<blockquote clas=
s=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc =
solid;padding-left:1ex">
<div dir=3D"ltr">Paper N3748 (<a href=3D"https://groups.google.com/a/isocpp=
..org/forum/?fromgroups#!newtopic/std-proposals" target=3D"_blank">Implicit =
Evaluation of auto Variables and Arguments</a>) proposes an "operator auto"=
 to handle the problems that auto has with expression templates and similar=
 classes.&nbsp; If a class Foo defines a member function operator auto() re=
turning type Bar, then in the code<br>
<br><div style=3D"background-color:rgb(250,250,250);border-color:rgb(187,18=
7,187);border-style:solid;border-width:1px;word-wrap:break-word"><code><div=
><span style=3D"color:#606">Foo</span><span> foo</span><span style=3D"color=
:#660">;</span><span><br>
</span><span style=3D"color:#008">auto</span><span> x </span><span style=3D=
"color:#660">=3D</span><span> foo</span><span style=3D"color:#660">;</span>=
<span><br></span></div></code></div><br>the type of x would be Bar and not =
Foo.&nbsp; While I think this a good idea, I think that there are some item=
s that are missing:<br>
<br>1) How does this interact with the C++14 decltype(auto) construct?&nbsp=
; I would expect the code<br><div style=3D"background-color:rgb(250,250,250=
);border-color:rgb(187,187,187);border-style:solid;border-width:1px;word-wr=
ap:break-word">
<code><div><span style=3D"color:#008">decltype</span><span style=3D"color:#=
660">(</span><span style=3D"color:#008">auto</span><span style=3D"color:#66=
0">)</span><span> y </span><span style=3D"color:#660">=3D</span><span> foo<=
/span><span style=3D"color:#660">;</span><span><br>
</span></div></code></div><br>to actually declare an object of type Foo, de=
spite the existence of the operator auto() function.&nbsp; The paper curren=
tly uses "explicit auto" to disable operator auto, but using decltype(auto)=
 for this would fit in better with existing rules.<br>
</div></blockquote></div><div><br>That's... problematic. `decltype(auto)` h=
as a very different set of type deduction rules for expressions than `auto`=
.. I wouldn't want to have to be forced into the `decltype(auto)` syntax jus=
t to get a variable of the actual expression's type.<br>
<br>That being said, `decltype(auto)` very much should deduce the actual ty=
pe. It just shouldn't be the <i>only</i> way to do so.<br></div></div></blo=
ckquote><div><br></div><div>I don't know how you come to such conclusions. =
The purpose of decltype(auto) is not deducing an "actual type"<br>
in this sense. I would expect decltype(auto) y =3D foo; to invoke an operat=
or auto of foo's type, if any, and needing<br>to use explicit decltype(auto=
) y =3D foo; if I don't want operator auto to be invoked.<br></div></div></=
div></div></blockquote><div><br>The thing is, the rules for `auto` type ded=
uction, template type deduction, and so forth are all the same (minus one c=
aveat). The rules for `decltype` type deduction are <i>different</i> from t=
hem. Since it already has differences in the way it deduces the type of an =
expression, there's no specific expectation or requirement that `decltype(a=
uto) y =3D foo;` to deduce the same type as `auto y =3D foo;`. Indeed, if y=
ou <i>wanted</i> the same type deduction, you wouldn't have used `decltype(=
auto)` at all.<br><br>Decltype deduction is different from regular type ded=
uction for a reason.<br><br>I'm not saying that it <i>couldn't</i> work. I'=
m saying that it shouldn't work just because; that there needs to be some s=
pecific reason why users would expect it to work. Remember: the only people=
 who would use `decltype(auto)` are those who know what that is and know th=
eir type deduction rules well enough to know that they need that in this sc=
enario. And those people probably don't <i>want</i> the deduction to use `o=
perator auto`.</div><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 />

------=_Part_2505_8844788.1378377656359--

.

--e89a8fb1ef64818cb404e5a0c0df
Content-Type: text/plain; charset=ISO-8859-1

On 5 September 2013 13:40, Nicol Bolas <jmckesson@gmail.com> wrote:

>
>
> On Thursday, September 5, 2013 3:02:38 AM UTC-7, Ville Voutilainen wrote:
>
>>
>>
>>
>> On 5 September 2013 12:33, Nicol Bolas <jmck...@gmail.com> wrote:
>>
>>> On Wednesday, September 4, 2013 7:30:01 PM UTC-7, jgot...@gmail.comwrote:
>>>>
>>>> Paper N3748 (Implicit Evaluation of auto Variables and Arguments<https://groups.google.com/a/isocpp.org/forum/?fromgroups#!newtopic/std-proposals>)
>>>> proposes an "operator auto" to handle the problems that auto has with
>>>> expression templates and similar classes.  If a class Foo defines a member
>>>> function operator auto() returning type Bar, then in the code
>>>>
>>>> Foo foo;
>>>> auto x = foo;
>>>>
>>>> the type of x would be Bar and not Foo.  While I think this a good
>>>> idea, I think that there are some items that are missing:
>>>>
>>>> 1) How does this interact with the C++14 decltype(auto) construct?  I
>>>> would expect the code
>>>> decltype(auto) y = foo;
>>>>
>>>> to actually declare an object of type Foo, despite the existence of the
>>>> operator auto() function.  The paper currently uses "explicit auto" to
>>>> disable operator auto, but using decltype(auto) for this would fit in
>>>> better with existing rules.
>>>>
>>>
>>> That's... problematic. `decltype(auto)` has a very different set of type
>>> deduction rules for expressions than `auto`. I wouldn't want to have to be
>>> forced into the `decltype(auto)` syntax just to get a variable of the
>>> actual expression's type.
>>>
>>> That being said, `decltype(auto)` very much should deduce the actual
>>> type. It just shouldn't be the *only* way to do so.
>>>
>>
>> I don't know how you come to such conclusions. The purpose of
>> decltype(auto) is not deducing an "actual type"
>> in this sense. I would expect decltype(auto) y = foo; to invoke an
>> operator auto of foo's type, if any, and needing
>> to use explicit decltype(auto) y = foo; if I don't want operator auto to
>> be invoked.
>>
>
> The thing is, the rules for `auto` type deduction, template type
> deduction, and so forth are all the same (minus one caveat). The rules for
> `decltype` type deduction are *different* from them. Since it already has
> differences in the way it deduces the type of an expression, there's no
> specific expectation or requirement that `decltype(auto) y = foo;` to
> deduce the same type as `auto y = foo;`. Indeed, if you *wanted* the same
> type deduction, you wouldn't have used `decltype(auto)` at all.
>
> Decltype deduction is different from regular type deduction for a reason.
>
> I'm not saying that it *couldn't* work. I'm saying that it shouldn't work
> just because; that there needs to be some specific reason why users would
> expect it to work. Remember: the only people who would use `decltype(auto)`
> are those who know what that is and know their type deduction rules well
> enough to know that they need that in this scenario. And those people
> probably don't *want* the deduction to use `operator auto`.
>
>
Thanks, I understand your reasoning, but whether operator auto kicks in and
whether auto or decltype(auto) are used
seem quite orthogonal to me, so if people don't want decltype(auto)
deduction to invoke an operator auto, they
should use the same mechanism for disabling operator auto that auto uses,
aka explicit, as proposed in the paper.

--

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

--e89a8fb1ef64818cb404e5a0c0df
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 5 September 2013 13:40, Nicol Bolas <span dir=3D"ltr">&lt;<a hre=
f=3D"mailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@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 dir=3D"ltr"><br><br>On Thursday, Septem=
ber 5, 2013 3:02:38 AM UTC-7, Ville Voutilainen wrote:<div class=3D"im"><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-l=
eft:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr"><br><div><br><br><div class=3D"gmail_quote">On 5 September=
 2013 12:33, Nicol Bolas <span dir=3D"ltr">&lt;<a>jmck...@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 dir=3D"ltr"><div>On Wednesday, Septembe=
r 4, 2013 7:30:01 PM UTC-7, <a>jgot...@gmail.com</a> wrote:<blockquote clas=
s=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc =
solid;padding-left:1ex">

<div dir=3D"ltr">Paper N3748 (<a href=3D"https://groups.google.com/a/isocpp=
..org/forum/?fromgroups#!newtopic/std-proposals" target=3D"_blank">Implicit =
Evaluation of auto Variables and Arguments</a>) proposes an &quot;operator =
auto&quot; to handle the problems that auto has with expression templates a=
nd similar classes.=A0 If a class Foo defines a member function operator au=
to() returning type Bar, then in the code<br>

<br><div style=3D"background-color:rgb(250,250,250);border-color:rgb(187,18=
7,187);border-style:solid;border-width:1px;word-wrap:break-word"><code><div=
><span style=3D"color:#606">Foo</span><span> foo</span><span style=3D"color=
:#660">;</span><span><br>

</span><span style=3D"color:#008">auto</span><span> x </span><span style=3D=
"color:#660">=3D</span><span> foo</span><span style=3D"color:#660">;</span>=
<span><br></span></div></code></div><br>the type of x would be Bar and not =
Foo.=A0 While I think this a good idea, I think that there are some items t=
hat are missing:<br>

<br>1) How does this interact with the C++14 decltype(auto) construct?=A0 I=
 would expect the code<br><div style=3D"background-color:rgb(250,250,250);b=
order-color:rgb(187,187,187);border-style:solid;border-width:1px;word-wrap:=
break-word">

<code><div><span style=3D"color:#008">decltype</span><span style=3D"color:#=
660">(</span><span style=3D"color:#008">auto</span><span style=3D"color:#66=
0">)</span><span> y </span><span style=3D"color:#660">=3D</span><span> foo<=
/span><span style=3D"color:#660">;</span><span><br>

</span></div></code></div><br>to actually declare an object of type Foo, de=
spite the existence of the operator auto() function.=A0 The paper currently=
 uses &quot;explicit auto&quot; to disable operator auto, but using decltyp=
e(auto) for this would fit in better with existing rules.<br>

</div></blockquote></div><div><br>That&#39;s... problematic. `decltype(auto=
)` has a very different set of type deduction rules for expressions than `a=
uto`. I wouldn&#39;t want to have to be forced into the `decltype(auto)` sy=
ntax just to get a variable of the actual expression&#39;s type.<br>

<br>That being said, `decltype(auto)` very much should deduce the actual ty=
pe. It just shouldn&#39;t be the <i>only</i> way to do so.<br></div></div><=
/blockquote><div><br></div><div>I don&#39;t know how you come to such concl=
usions. The purpose of decltype(auto) is not deducing an &quot;actual type&=
quot;<br>

in this sense. I would expect decltype(auto) y =3D foo; to invoke an operat=
or auto of foo&#39;s type, if any, and needing<br>to use explicit decltype(=
auto) y =3D foo; if I don&#39;t want operator auto to be invoked.<br></div>
</div></div></div></blockquote></div><div><br>The thing is, the rules for `=
auto` type deduction, template type deduction, and so forth are all the sam=
e (minus one caveat). The rules for `decltype` type deduction are <i>differ=
ent</i> from them. Since it already has differences in the way it deduces t=
he type of an expression, there&#39;s no specific expectation or requiremen=
t that `decltype(auto) y =3D foo;` to deduce the same type as `auto y =3D f=
oo;`. Indeed, if you <i>wanted</i> the same type deduction, you wouldn&#39;=
t have used `decltype(auto)` at all.<br>
<br>Decltype deduction is different from regular type deduction for a reaso=
n.<br><br>I&#39;m not saying that it <i>couldn&#39;t</i> work. I&#39;m sayi=
ng that it shouldn&#39;t work just because; that there needs to be some spe=
cific reason why users would expect it to work. Remember: the only people w=
ho would use `decltype(auto)` are those who know what that is and know thei=
r type deduction rules well enough to know that they need that in this scen=
ario. And those people probably don&#39;t <i>want</i> the deduction to use =
`operator auto`.</div>
<br></div></blockquote><div><br></div><div>Thanks, I understand your reason=
ing, but whether operator auto kicks in and whether auto or decltype(auto) =
are used<br></div><div>seem quite orthogonal to me, so if people don&#39;t =
want decltype(auto) deduction to invoke an operator auto, they<br>
should use the same mechanism for disabling operator auto that auto uses, a=
ka explicit, as proposed in the paper. <br></div></div><br></div><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 />

--e89a8fb1ef64818cb404e5a0c0df--

.