------=_Part_861_23396914.1404593526108
Content-Type: text/plain; charset=UTF-8

In the paper N4078 <https://isocpp.org/files/papers/N4078.html> two Rvalue
reference overloads was added to the optional<T> class:
  constexpr T value() &&;
  constexpr T value() const&&
I think this overloads should return by r-value reference instead.
  constexpr T&& value() &&;

*I am not aware of any other motivation for this change, please post if
other one exists.*
Lets begin with the motivation for current desing. As far as I know this
was introduced to make
following code well-behaved:
  optional<string> f();
  auto&& s = f().value(); //this code creates a dangling reference if we
would return by reference
I don think making this well-behaved makes more harm that good. It adds
single exceptional class
int the langugage for which such code is well behaved. For example if we
write very similiar code
with a vector or std::tuple, this code wil still create a dangling
reference.
  std::vector<std::string> f();
  auto&& s = f.front(); //dangling reference
  std::tuple<std::string, exception_ptr> g();
  auto&& s = get<0>(g()); //this is emulation of expected<T> or optional<T>
with tuple
So the standard library is not consistent with the behaviour, and even if
we fix every getter method
in the standard by adding rvalue overload, the problem still won't be fixed
without changing language
in case of the members:
  std::pair<std::string, exception_ptr> g();
  auto&& s = g().first; //will create a dangling reference

So to summarize:
Now we have single class in the standard that provides the rvalue reference
overload for getter method
and make the auto&& s = f().value() well defined. But this is not and
cannot be uniformly applied to
the rest of the language (because of member access). This in my opinion
makes language more complicated
and leave the programmer with two options:
  - remember this special case and apply them when possible
  - ignore existence of this overloads

In addition the current desings introduces preformance impact on the code.
Let assume following:
    optional<T> f();
    void g(const T&);o

   vector<T> vt; vt.emplace_back(f.value());
   g(f().value());
   This following two lines will now introduce additional move-construction
o value of type T.
   Someone may argue that this cost is not large becase move are cheap (for
example std::string). But in the working codebase that
   is a lot of legacy classes that are not move-constructible and this will
introduce additional unecessary cost. Of course this
   problem does not exists for tuple or pairs.

In my opinion it would be better to delcaret this functions as returning
reference because it will make it consistent with rest of the language
and by doing it will make it easier to use and understand.

--

---
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_861_23396914.1404593526108
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><span style=3D"font-family: arial,sans-serif;">In the pape=
r </span><a style=3D"font-family: arial,sans-serif;" href=3D"https://isocpp=
..org/files/papers/N4078.html">N4078</a><span style=3D"font-family: arial,sa=
ns-serif;"> two Rvalue reference overloads was added to the optional&lt;T&g=
t; class:</span><br style=3D"font-family: arial,sans-serif;"><code><span st=
yle=3D"font-family: arial,sans-serif;">&nbsp; constexpr T value() &amp;&amp=
;;</span><br style=3D"font-family: arial,sans-serif;"><span style=3D"font-f=
amily: arial,sans-serif;">&nbsp; constexpr T value() const&amp;&amp;</span>=
<br style=3D"font-family: arial,sans-serif;"><span style=3D"font-family: ar=
ial,sans-serif;">I think this overloads should return by r-value reference =
instead. <br></span></code><code><span style=3D"font-family: arial,sans-ser=
if;">&nbsp; constexpr T&amp;&amp; value() &amp;&amp;;</span></code><br><cod=
e><span style=3D"font-family: arial,sans-serif;"><br><b>I am not aware of a=
ny other motivation for this change, please post if other one exists.</b><b=
r>Lets begin with the motivation for current desing. As far as I know this =
was introduced to make <br>following code well-behaved:<br>&nbsp; optional&=
lt;string&gt; f();<br>&nbsp; auto&amp;&amp; s =3D f().value(); //this code =
creates a dangling reference if we would return by reference<br>I don think=
 making this well-behaved makes more harm that good. It adds single excepti=
onal class<br>int the langugage for which such code is well behaved. For ex=
ample if we write very similiar code<br>with a vector or std::tuple, this c=
ode wil still create a dangling reference.<br>&nbsp; std::vector&lt;std::st=
ring&gt; f();<br>&nbsp; auto&amp;&amp; s =3D f.front(); //dangling referenc=
e<br>&nbsp; std::tuple&lt;std::string, exception_ptr&gt; g();<br>&nbsp; aut=
o&amp;&amp; s =3D get&lt;0&gt;(g()); //this is emulation of expected&lt;T&g=
t; or optional&lt;T&gt; with tuple<br>So the standard library is not consis=
tent with the behaviour, and even if we fix every getter method<br>in the s=
tandard by adding rvalue overload, the problem still won't be fixed without=
 changing language<br>in case of the members:<br></span></code><code><span =
style=3D"font-family: arial,sans-serif;">&nbsp; std::pair&lt;std::string, e=
xception_ptr&gt; g();<br>
&nbsp; auto&amp;&amp; s =3D g().first; //will create a dangling reference<b=
r><br>So to summarize:<br>Now we have single class in the standard that pro=
vides the rvalue reference overload for getter method<br>and make the auto&=
amp;&amp; s =3D f().value() well defined. But this is not and cannot be uni=
formly applied to<br>the rest of the language (because of member access). T=
his in my opinion makes language more complicated<br>and leave the programm=
er with two options:<br>&nbsp; - remember this special case and apply them =
when possible<br>&nbsp; - ignore existence of this overloads<br><br>In addi=
tion the current desings introduces preformance impact on the code. Let ass=
ume following:<br>&nbsp;&nbsp;&nbsp; optional&lt;T&gt; f();<br>&nbsp;&nbsp;=
&nbsp; void g(const T&amp;);o<br>&nbsp; <br>&nbsp;&nbsp; vector&lt;T&gt; vt=
; vt.emplace_back(f.value()); <br>&nbsp;&nbsp; g(f().value());<br>&nbsp;&nb=
sp; This following two lines will now introduce additional move-constructio=
n o value of type T.<br>&nbsp;&nbsp; Someone may argue that this cost is no=
t large becase move are cheap (for example std::string). But in the working=
 codebase that<br>&nbsp;&nbsp; is a lot of legacy classes that are not move=
-constructible and this will introduce additional unecessary cost. Of cours=
e this<br>&nbsp;&nbsp; problem does not exists for tuple or pairs.<br>&nbsp=
;<br>In my opinion it would be better to delcaret this functions as returni=
ng reference because it will make it consistent with rest of the language<b=
r>and by doing it will make it easier to use and understand.<br></span></co=
de></div>

<p></p>

-- <br />
<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 <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_861_23396914.1404593526108--

.