------=_Part_125_22173508.1404904903166
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



W dniu sobota, 5 lipca 2014 22:52:06 UTC+2 u=C5=BCytkownik anna.s...@gmail.=
com=20
napisa=C5=82:
>
> In the paper N4078 <https://isocpp.org/files/papers/N4078.html> two=20
> 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.=20
>   constexpr T&& value() &&;
>
> *I am not aware of any other motivation for this change, please post if=
=20
> other one exists.*
> Lets begin with the motivation for current desing. As far as I know this=
=20
> was introduced to make=20
> following code well-behaved:
>   optional<string> f();
>   auto&& s =3D f().value(); //this code creates a dangling reference if w=
e=20
> would return by reference
> I don think making this well-behaved makes more harm that good. It adds=
=20
> single exceptional class
> int the langugage for which such code is well behaved. For example if we=
=20
> write very similiar code
> with a vector or std::tuple, this code wil still create a dangling=20
> reference.
>   std::vector<std::string> f();
>   auto&& s =3D f.front(); //dangling reference
>   std::tuple<std::string, exception_ptr> g();
>   auto&& s =3D get<0>(g()); //this is emulation of expected<T> or=20
> optional<T> with tuple
> So the standard library is not consistent with the behaviour, and even if=
=20
> we fix every getter method
> in the standard by adding rvalue overload, the problem still won't be=20
> fixed without changing language
> in case of the members:
>   std::pair<std::string, exception_ptr> g();
>   auto&& s =3D g().first; //will create a dangling reference
>
> So to summarize:
> Now we have single class in the standard that provides the rvalue=20
> reference overload for getter method
> and make the auto&& s =3D f().value() well defined. But this is not and=
=20
> cannot be uniformly applied to
> the rest of the language (because of member access). This in my opinion=
=20
> 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=
..=20
> Let assume following:
>     optional<T> f();
>     void g(const T&);o
>  =20
>    vector<T> vt; vt.emplace_back(f.value());=20
>    g(f().value());
>    This following two lines will now introduce additional=20
> move-construction o value of type T.
>    Someone may argue that this cost is not large becase move are cheap=20
> (for example std::string). But in the working codebase that
>    is a lot of legacy classes that are not move-constructible and this=20
> will introduce additional unecessary cost. Of course this
>    problem does not exists for tuple or pairs.
> =20
> In my opinion it would be better to delcaret this functions as returning=
=20
> reference because it will make it consistent with rest of the language
> and by doing it will make it easier to use and understand.
>

The only motivation for returning by value -- to the best of my knowledge=
=20
-- is the avoidance of dangling references in certain cases. My=20
understanding is that LEWG preferred these to return by value, even at the=
=20
expense of incurring run-time overhead. My personal motivation was to=20
minimize the controversy with LEWG and increasing the chances of getting=20
the proposal through. (Rvalue ref overloads returning by value are better=
=20
than no rvalue ref overloads.)

I hope LEWG members are reading this list and can shed some more light on=
=20
this question.

Regards,
&rzej

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

<div dir=3D"ltr"><br><br>W dniu sobota, 5 lipca 2014 22:52:06 UTC+2 u=C5=BC=
ytkownik anna.s...@gmail.com napisa=C5=82:<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"><span style=3D"font-family:arial,sans-serif">I=
n the paper </span><a style=3D"font-family:arial,sans-serif" href=3D"https:=
//isocpp.org/files/papers/N4078.html" target=3D"_blank" onmousedown=3D"this=
..href=3D'https://www.google.com/url?q\75https%3A%2F%2Fisocpp.org%2Ffiles%2F=
papers%2FN4078.html\46sa\75D\46sntz\0751\46usg\75AFQjCNHCY0rGdgNwK1xSqCTZsz=
7l9ecf6g';return true;" onclick=3D"this.href=3D'https://www.google.com/url?=
q\75https%3A%2F%2Fisocpp.org%2Ffiles%2Fpapers%2FN4078.html\46sa\75D\46sntz\=
0751\46usg\75AFQjCNHCY0rGdgNwK1xSqCTZsz7l9ecf6g';return true;">N4078</a><sp=
an style=3D"font-family:arial,sans-serif"> two Rvalue reference overloads w=
as added to the optional&lt;T&gt; class:</span><br style=3D"font-family:ari=
al,sans-serif"><code><span style=3D"font-family:arial,sans-serif">&nbsp; co=
nstexpr T value() &amp;&amp;;</span><br style=3D"font-family:arial,sans-ser=
if"><span style=3D"font-family:arial,sans-serif">&nbsp; constexpr T value()=
 const&amp;&amp;</span><br style=3D"font-family:arial,sans-serif"><span sty=
le=3D"font-family:arial,sans-serif">I think this overloads should return by=
 r-value reference instead. <br></span></code><code><span style=3D"font-fam=
ily:arial,sans-serif">&nbsp; constexpr T&amp;&amp; value() &amp;&amp;;</spa=
n></code><br><code><span style=3D"font-family:arial,sans-serif"><br><b>I am=
 not aware of any other motivation for this change, please post if other on=
e exists.</b><br>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 exceptional class<br>int the langugage for which such code is well =
behaved. For example if we write very similiar code<br>with a vector or std=
::tuple, this code wil still create a dangling reference.<br>&nbsp; std::ve=
ctor&lt;std::string&gt; f();<br>&nbsp; auto&amp;&amp; s =3D f.front(); //da=
ngling reference<br>&nbsp; std::tuple&lt;std::string, exception_ptr&gt; g()=
;<br>&nbsp; auto&amp;&amp; s =3D get&lt;0&gt;(g()); //this is emulation of =
expected&lt;T&gt; or optional&lt;T&gt; with tuple<br>So the standard librar=
y is not consistent with the behaviour, and even if we fix every getter met=
hod<br>in the standard by adding rvalue overload, the problem still won't b=
e fixed without changing language<br>in case of the members:<br></span></co=
de><code><span style=3D"font-family:arial,sans-serif">&nbsp; std::pair&lt;s=
td::string, exception_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></blockquote><div><br>The only motivation for returning by value -=
- to the best of my knowledge -- is the avoidance of dangling references in=
 certain cases. My understanding is that LEWG preferred these to return by =
value, even at the expense of incurring run-time overhead. My personal moti=
vation was to minimize the controversy with LEWG and increasing the chances=
 of getting the proposal through. (Rvalue ref overloads returning by value =
are better than no rvalue ref overloads.)<br><br>I hope LEWG members are re=
ading this list and can shed some more light on this question.<br><br>Regar=
ds,<br>&amp;rzej<br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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_125_22173508.1404904903166--

.

On 9 July 2014 14:21, Andrzej Krzemie=C5=84ski <akrzemi1@gmail.com> wrote:
>
>
> W dniu sobota, 5 lipca 2014 22:52:06 UTC+2 u=C5=BCytkownik anna.s...@gmai=
l.com
> napisa=C5=82:
>>
>> In the paper N4078 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 =3D 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 =3D f.front(); //dangling reference
>>   std::tuple<std::string, exception_ptr> g();
>>   auto&& s =3D 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 i=
f
>> 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 =3D 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 =3D 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 cod=
e.
>> 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.
>
>
> The only motivation for returning by value -- to the best of my knowledge=
 --
> is the avoidance of dangling references in certain cases. My understandin=
g
> is that LEWG preferred these to return by value, even at the expense of
> incurring run-time overhead. My personal motivation was to minimize the
> controversy with LEWG and increasing the chances of getting the proposal
> through. (Rvalue ref overloads returning by value are better than no rval=
ue
> ref overloads.)
>
> I hope LEWG members are reading this list and can shed some more light on
> this question.


The understanding of both of you is correct; I personally pointed out
the potential
problem with dangling references in rvalue cases, and LEWG portrayed
(not very strong) preference to having these functions return by value.

I think it would be fair to consider a wider-scope fix. I doubt such a
change would
get accepted to the standard library at large. Adding it to the
issues-to-consider
for a next-gen standard library would be a good idea. I also think it
would be sane
to consider some sort of a language feature to return a reference for
an lvalue object
and a value for an rvalue object, semi-automatically. I suppose it
would be a possible
idea to extend the language to know more precisely whether the context
of the returned
object is something that can lead into a dangling case or not.

I think the point about emplace for a legacy type moving twice, and
that move actually being a copy,
is a decent thing to consider. Thus far we're in a Technical
Specification going out for its
first ballot round, so there's time to fix things, if the committee so
chooses. I personally
have no quantification about whether optional rvalues are common
enough to justify
the inconsistency with the other parts of the library, or whether
accessing subobjects
of such rvalues by references happen often or at all. The change was a
judgment call
rather than a change backed by strong data, I must admit.

--=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_3_23298446.1404930856471
Content-Type: text/plain; charset=UTF-8

I want point out one other think that I run into, when I was creating a
handle_value_or_optional in
https://groups.google.com/a/isocpp.org/forum/?fromgroups#!topic/std-proposals/RTUK2xO0tzs.
I will provide here shorter version. Let assume we want to have the
following function handle_optional(opt, fv, fn) that when opt has value
will invoke fv(*opt) otherwis fn.

I we have the r-value reference qualified operator* and value method
(instead of returning by value) I can write:
template<typename U, typename FV, typename FN> //I removed the checking
form this function to make it simpler
delctype(auto) handle_optional(U&& u, FV&& fv, FN&& fn)
{
  return u ? std::forward<FV>(fv)(*std::forward<U>(u)) :
std::forward<FN>(fn);
}
Because *std::forward<U>(u) will return a rvalue reference if such overload
exists. If the optional has no rvalue refence method
or the one returning value I must write to avoid making uncessary
temporaries:
template<typename U, typename FV, typename FN> //I removed the checking
form this function to make it simpler
delctype(auto) handle_optional(U&& u, FV&& fv, FN&& fn)
{
  return u ? std::forward<FV>(fv)(std::forward<same_cv_ref_t<typename
decay_t<U>::value_type, U&&>>(*u)) : std::forward<FN>(fn);
}
//The same_cv_ref_as_t is needed to use std::forward<T&&> if optional<T>&&
is passed as first argument type. And actually this works because
u is lvalue here.



--

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

------=_Part_3_23298446.1404930856471
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I want point out one other think that I run into, when I w=
as creating a handle_value_or_optional in https://groups.google.com/a/isocp=
p.org/forum/?fromgroups#!topic/std-proposals/RTUK2xO0tzs.<br>I will provide=
 here shorter version. Let assume we want to have the following function ha=
ndle_optional(opt, fv, fn) that when opt has value will invoke fv(*opt) oth=
erwis fn.<br><br>I we have the r-value reference qualified operator* and va=
lue method (instead of returning by value) I can write:<br>template&lt;type=
name U, typename FV, typename FN&gt; //I removed the checking form this fun=
ction to make it simpler<br>delctype(auto) handle_optional(U&amp;&amp; u, F=
V&amp;&amp; fv, FN&amp;&amp; fn)<br>{<br>&nbsp; return u ? std::forward&lt;=
FV&gt;(fv)(*std::forward&lt;U&gt;(u)) : std::forward&lt;FN&gt;(fn);<br>}<br=
>Because *std::forward&lt;U&gt;(u) will return a rvalue reference if such o=
verload exists. If the optional has no rvalue refence method<br>or the one =
returning value I must write to avoid making uncessary temporaries:<br>temp=
late&lt;typename U, typename FV, typename FN&gt; //I removed the checking f=
orm this function to make it simpler<br>delctype(auto) handle_optional(U&am=
p;&amp; u, FV&amp;&amp; fv, FN&amp;&amp; fn)<br>{<br>&nbsp; return u ? std:=
:forward&lt;FV&gt;(fv)(std::forward&lt;same_cv_ref_t&lt;typename decay_t&lt=
;U&gt;::value_type, U&amp;&amp;&gt;&gt;(*u)) : std::forward&lt;FN&gt;(fn);<=
br>}<br>//The same_cv_ref_as_t is needed to use std::forward&lt;T&amp;&amp;=
&gt; if optional&lt;T&gt;&amp;&amp; is passed as first argument type. And a=
ctually this works because<br>u is lvalue here.<br><br><br><br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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_3_23298446.1404930856471--

.

On 9 July 2014 21:34,  <tomaszkam@gmail.com> wrote:
> I want point out one other think that I run into, when I was creating a
> handle_value_or_optional in
> https://groups.google.com/a/isocpp.org/forum/?fromgroups#!topic/std-proposals/RTUK2xO0tzs.
> I will provide here shorter version. Let assume we want to have the
> following function handle_optional(opt, fv, fn) that when opt has value will
> invoke fv(*opt) otherwis fn.
>
> I we have the r-value reference qualified operator* and value method
> (instead of returning by value) I can write:
> template<typename U, typename FV, typename FN> //I removed the checking form
> this function to make it simpler
> delctype(auto) handle_optional(U&& u, FV&& fv, FN&& fn)
> {
>   return u ? std::forward<FV>(fv)(*std::forward<U>(u)) :
> std::forward<FN>(fn);
> }
> Because *std::forward<U>(u) will return a rvalue reference if such overload
> exists. If the optional has no rvalue refence method
> or the one returning value I must write to avoid making uncessary
> temporaries:
> template<typename U, typename FV, typename FN> //I removed the checking form
> this function to make it simpler
> delctype(auto) handle_optional(U&& u, FV&& fv, FN&& fn)
> {
>   return u ? std::forward<FV>(fv)(std::forward<same_cv_ref_t<typename
> decay_t<U>::value_type, U&&>>(*u)) : std::forward<FN>(fn);
> }
> //The same_cv_ref_as_t is needed to use std::forward<T&&> if optional<T>&&
> is passed as first argument type. And actually this works because
> u is lvalue here.

Ah, I see. Forwarding a dereferenced named value will never create a
temporary, *forward<U>(u)
might.

--

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

.

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

http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#1651 addresses:

  std::pair<std::string, exception_ptr> g();
  auto&& s = g().first; //will create a dangling reference

It's in 'ready' status, meaning it's not in C++14, but it's likely to get
fixed immediately after, possibly as a "defect", which would mean that most
compilers would implement the fix in their C++14 modes.

I agree that I'd rather see the general issue fixed by a language change
(probably involving a change to the library to use the new language
feature). I'm ambivalent about the safety fix we have in optional<>.
 On Jul 5, 2014 1:52 PM, <anna.salwa.05@gmail.com> wrote:

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

--

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

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

<div dir=3D"ltr"><p dir=3D"ltr"><a href=3D"http://www.open-std.org/jtc1/sc2=
2/wg21/docs/cwg_active.html#1651">http://www.open-std.org/jtc1/sc22/wg21/do=
cs/cwg_active.html#1651</a> addresses:</p><p dir=3D"ltr"><span style=3D"fon=
t-family:arial,sans-serif">=A0 std::pair&lt;std::string, exception_ptr&gt; =
g();</span><br style=3D"font-family:arial,sans-serif">

<span style=3D"font-family:arial,sans-serif">=A0 auto&amp;&amp; s =3D g().f=
irst; //will create a dangling reference</span><br></p><p>It&#39;s in &#39;=
ready&#39; status, meaning it&#39;s not in C++14, but it&#39;s likely to ge=
t fixed immediately after, possibly as a &quot;defect&quot;, which would me=
an that most compilers would implement the fix in their C++14 modes.</p>

<p>I agree that I&#39;d rather see the general issue fixed by a language ch=
ange (probably involving a change to the library to use the new language fe=
ature). I&#39;m ambivalent about the safety fix we have in optional&lt;&gt;=
..<br>

</p>
<div class=3D"gmail_quote">On Jul 5, 2014 1:52 PM,  &lt;<a href=3D"mailto:a=
nna.salwa.05@gmail.com" target=3D"_blank" class=3D"cremed">anna.salwa.05@gm=
ail.com</a>&gt; wrote:<br type=3D"attribution"><blockquote class=3D"gmail_q=
uote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-c=
olor:rgb(204,204,204);border-left-style:solid;padding-left:1ex">


<div dir=3D"ltr"><span style=3D"font-family:arial,sans-serif">In the paper =
</span><a style=3D"font-family:arial,sans-serif" href=3D"https://isocpp.org=
/files/papers/N4078.html" target=3D"_blank" class=3D"cremed">N4078</a><span=
 style=3D"font-family:arial,sans-serif"> two Rvalue reference overloads was=
 added to the optional&lt;T&gt; class:</span><br style=3D"font-family:arial=
,sans-serif">


<code><span style=3D"font-family:arial,sans-serif">=A0 constexpr T value() =
&amp;&amp;;</span><br style=3D"font-family:arial,sans-serif"><span style=3D=
"font-family:arial,sans-serif">=A0 constexpr T value() const&amp;&amp;</spa=
n><br style=3D"font-family:arial,sans-serif">


<span style=3D"font-family:arial,sans-serif">I think this overloads should =
return by r-value reference instead. <br></span></code><code><span style=3D=
"font-family:arial,sans-serif">=A0 constexpr T&amp;&amp; value() &amp;&amp;=
;</span></code><br>


<code><span style=3D"font-family:arial,sans-serif"><br><b>I am not aware of=
 any other motivation for this change, please post if other one exists.</b>=
<br>Lets begin with the motivation for current desing. As far as I know thi=
s was introduced to make <br>


following code well-behaved:<br>=A0 optional&lt;string&gt; f();<br>=A0 auto=
&amp;&amp; s =3D f().value(); //this code creates a dangling reference if w=
e would return by reference<br>I don think making this well-behaved makes m=
ore harm that good. It adds single exceptional class<br>


int the langugage for which such code is well behaved. For example if we wr=
ite very similiar code<br>with a vector or std::tuple, this code wil still =
create a dangling reference.<br>=A0 std::vector&lt;std::string&gt; f();<br>


=A0 auto&amp;&amp; s =3D f.front(); //dangling reference<br>=A0 std::tuple&=
lt;std::string, exception_ptr&gt; g();<br>=A0 auto&amp;&amp; s =3D get&lt;0=
&gt;(g()); //this is emulation of expected&lt;T&gt; or optional&lt;T&gt; wi=
th tuple<br>


So the standard library is not consistent with the behaviour, and even if w=
e fix every getter method<br>in the standard by adding rvalue overload, the=
 problem still won&#39;t be fixed without changing language<br>in case of t=
he members:<br>


</span></code><code><span style=3D"font-family:arial,sans-serif">=A0 std::p=
air&lt;std::string, exception_ptr&gt; g();<br>
=A0 auto&amp;&amp; s =3D g().first; //will create a dangling reference<br><=
br>So to summarize:<br>Now we have single class in the standard that provid=
es 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 unifor=
mly applied to<br>


the rest of the language (because of member access). This in my opinion mak=
es language more complicated<br>and leave the programmer with two options:<=
br>=A0 - remember this special case and apply them when possible<br>=A0 - i=
gnore existence of this overloads<br>


<br>In addition the current desings introduces preformance impact on the co=
de. Let assume following:<br>=A0=A0=A0 optional&lt;T&gt; f();<br>=A0=A0=A0 =
void g(const T&amp;);o<br>=A0 <br>=A0=A0 vector&lt;T&gt; vt; vt.emplace_bac=
k(f.value()); <br>


=A0=A0 g(f().value());<br>=A0=A0 This following two lines will now introduc=
e additional move-construction o value of type T.<br>=A0=A0 Someone may arg=
ue that this cost is not large becase move are cheap (for example std::stri=
ng). But in the working codebase that<br>


=A0=A0 is a lot of legacy classes that are not move-constructible and this =
will introduce additional unecessary cost. Of course this<br>=A0=A0 problem=
 does not exists for tuple or pairs.<br>=A0<br>In my opinion it would be be=
tter to delcaret this functions as returning reference because it will make=
 it consistent with rest of the language<br>


and by doing it will make it easier to use and understand.<br></span></code=
></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" target=3D"_=
blank" class=3D"cremed">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank" class=3D"cremed">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank" class=3D"cremed">http://groups.google.com=
/a/isocpp.org/group/std-proposals/</a>.<br>
</blockquote></div>
</div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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 />

--089e013a044ae9b88704fdc77274--

.

On 9 July 2014 22:09, 'Jeffrey Yasskin' via ISO C++ Standard - Future
Proposals <std-proposals@isocpp.org> wrote:
> http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#1651 addresses:
>
>   std::pair<std::string, exception_ptr> g();
>   auto&& s = g().first; //will create a dangling reference
>
> It's in 'ready' status, meaning it's not in C++14, but it's likely to get
> fixed immediately after, possibly as a "defect", which would mean that most
> compilers would implement the fix in their C++14 modes.
>
> I agree that I'd rather see the general issue fixed by a language change
> (probably involving a change to the library to use the new language
> feature). I'm ambivalent about the safety fix we have in optional<>.


I think the "yes, moving twice is fine, but what if the move ends up
copying?" issue
and the "perfect-forwarding the underlying value from an optional
becomes tricky"
issue are worth discussing in LEWG. They certainly change my (minor) preference.

--

---
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_335_18890479.1404933714826
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



W dniu =C5=9Broda, 9 lipca 2014 21:09:36 UTC+2 u=C5=BCytkownik Jeffrey Yass=
kin=20
napisa=C5=82:
>
> http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#1651=20
> addresses:
>
>   std::pair<std::string, exception_ptr> g();
>   auto&& s =3D g().first; //will create a dangling reference
>
> It's in 'ready' status, meaning it's not in C++14, but it's likely to get=
=20
> fixed immediately after, possibly as a "defect", which would mean that mo=
st=20
> compilers would implement the fix in their C++14 modes.
>
But it does not still fix the following:
  std::pair<std::string, exception_ptr> g();
  auto&& s =3D std::get<0>(g()); //will create a dangling reference
And I don not think that it is even possible to change meaning of the get=
=20
with lvalue because lot of code depends of that.
Or:
  auto f =3D std::mem_fn(A::member);
  /* ........... */
  auto&& s =3D f(g()); //will create a dangling reference
Actually I think taht the problem lies in the usage of auto&&, not in the=
=20
return types.

I agree that I'd rather see the general issue fixed by a language change=20
> (probably involving a change to the library to use the new language=20
> feature). I'm ambivalent about the safety fix we have in optional<>.
> =20
Actually just one other case from the library that come to my mind. Would=
=20
we want to make the following to do not create dangling reference:
    std::vector<std::string> f();
    auto&& s =3D *f.begin(); //dangling reference
This will require us the create a begin/end r-value overload that returns=
=20
same kind of copy-iterator that return by value when *it is invoked. I am=
=20
not
sure what consequence will it have.
=20

> On Jul 5, 2014 1:52 PM, <anna.s...@gmail.com <javascript:>> wrote:
>
>> In the paper N4078 <https://isocpp.org/files/papers/N4078.html> two=20
>> 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.=20
>>   constexpr T&& value() &&;
>>
>> *I am not aware of any other motivation for this change, please post if=
=20
>> other one exists.*
>> Lets begin with the motivation for current desing. As far as I know this=
=20
>> was introduced to make=20
>> following code well-behaved:
>>   optional<string> f();
>>   auto&& s =3D f().value(); //this code creates a dangling reference if =
we=20
>> would return by reference
>> I don think making this well-behaved makes more harm that good. It adds=
=20
>> single exceptional class
>> int the langugage for which such code is well behaved. For example if we=
=20
>> write very similiar code
>> with a vector or std::tuple, this code wil still create a dangling=20
>> reference.
>>   std::vector<std::string> f();
>>   auto&& s =3D f.front(); //dangling reference
>>   std::tuple<std::string, exception_ptr> g();
>>   auto&& s =3D get<0>(g()); //this is emulation of expected<T> or=20
>> optional<T> with tuple
>> So the standard library is not consistent with the behaviour, and even i=
f=20
>> we fix every getter method
>> in the standard by adding rvalue overload, the problem still won't be=20
>> fixed without changing language
>> in case of the members:
>>   std::pair<std::string, exception_ptr> g();
>>   auto&& s =3D g().first; //will create a dangling reference
>>
>> So to summarize:
>> Now we have single class in the standard that provides the rvalue=20
>> reference overload for getter method
>> and make the auto&& s =3D f().value() well defined. But this is not and=
=20
>> cannot be uniformly applied to
>> the rest of the language (because of member access). This in my opinion=
=20
>> 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=20
>> code. Let assume following:
>>     optional<T> f();
>>     void g(const T&);o
>>  =20
>>    vector<T> vt; vt.emplace_back(f.value());=20
>>    g(f().value());
>>    This following two lines will now introduce additional=20
>> move-construction o value of type T.
>>    Someone may argue that this cost is not large becase move are cheap=
=20
>> (for example std::string). But in the working codebase that
>>    is a lot of legacy classes that are not move-constructible and this=
=20
>> will introduce additional unecessary cost. Of course this
>>    problem does not exists for tuple or pairs.
>> =20
>> In my opinion it would be better to delcaret this functions as returning=
=20
>> reference because it will make it consistent with rest of the language
>> and by doing it will make it easier to use and understand.
>>
>> --=20
>>
>> ---=20
>> You received this message because you are subscribed to the Google Group=
s=20
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n=20
>> email to std-proposal...@isocpp.org <javascript:>.
>> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>> Visit this group at=20
>> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>>
>=20

--=20

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

------=_Part_335_18890479.1404933714826
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>W dniu =C5=9Broda, 9 lipca 2014 21:09:36 UTC+2 u=
=C5=BCytkownik Jeffrey Yasskin napisa=C5=82:<blockquote class=3D"gmail_quot=
e" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddin=
g-left: 1ex;"><div dir=3D"ltr"><p dir=3D"ltr"><a href=3D"http://www.open-st=
d.org/jtc1/sc22/wg21/docs/cwg_active.html#1651" target=3D"_blank" onmousedo=
wn=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fwww.open-std.=
org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fcwg_active.html%231651\46sa\75D\46sntz\07=
51\46usg\75AFQjCNHVoie10PZYFxvkX-eVFGjeRad_GQ';return true;" onclick=3D"thi=
s.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fwww.open-std.org%2Fjtc=
1%2Fsc22%2Fwg21%2Fdocs%2Fcwg_active.html%231651\46sa\75D\46sntz\0751\46usg\=
75AFQjCNHVoie10PZYFxvkX-eVFGjeRad_GQ';return true;">http://www.open-std.org=
/jtc1/<wbr>sc22/wg21/docs/cwg_active.<wbr>html#1651</a> addresses:</p><p di=
r=3D"ltr"><span style=3D"font-family:arial,sans-serif">&nbsp; std::pair&lt;=
std::string, exception_ptr&gt; g();</span><br style=3D"font-family:arial,sa=
ns-serif">

<span style=3D"font-family:arial,sans-serif">&nbsp; auto&amp;&amp; s =3D g(=
).first; //will create a dangling reference</span><br></p><p>It's in 'ready=
' status, meaning it's not in C++14, but it's likely to get fixed immediate=
ly after, possibly as a "defect", which would mean that most compilers woul=
d implement the fix in their C++14 modes.</p></div></blockquote><div>But it=
 does not still fix the following:<br>&nbsp;<span style=3D"font-family:aria=
l,sans-serif"> std::pair&lt;std::string, exception_ptr&gt; g();</span><br s=
tyle=3D"font-family:arial,sans-serif">

<span style=3D"font-family:arial,sans-serif">&nbsp; auto&amp;&amp; s =3D st=
d::get&lt;0&gt;(g()); //will create a dangling reference</span><br>And I do=
n not think that it is even possible to change meaning of the get with lval=
ue because lot of code depends of that.<br>Or:<br>&nbsp; auto f =3D std::me=
m_fn(A::member);<br>&nbsp; /* ........... */<br>&nbsp; <span style=3D"font-=
family:arial,sans-serif">auto&amp;&amp; s =3D f(g()); //will create a dangl=
ing reference</span><br>Actually I think taht the problem lies in the usage=
 of auto&amp;&amp;, not in the return types.<br><br></div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;"><div dir=3D"ltr">

<p>I agree that I'd rather see the general issue fixed by a language change=
 (probably involving a change to the library to use the new language featur=
e). I'm ambivalent about the safety fix we have in optional&lt;&gt;.<br>

</p>
<div class=3D"gmail_quote"></div></div></blockquote><div>Actually just one =
other case from the library that come to my mind. Would we want to make the=
 following to do not create dangling reference:<br>&nbsp;&nbsp;&nbsp; std::=
vector&lt;std::string&gt; f();<br>&nbsp;&nbsp;&nbsp; auto&amp;&amp; s =3D *=
f.begin(); //dangling reference<br>This will require us the create a begin/=
end r-value overload that returns same kind of copy-iterator that return by=
 value when *it is invoked. I am not<br>sure what consequence will it have.=
<br>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"lt=
r"><div class=3D"gmail_quote">On Jul 5, 2014 1:52 PM,  &lt;<a href=3D"javas=
cript:" target=3D"_blank" gdf-obfuscated-mailto=3D"jqJB6k03cWAJ" onmousedow=
n=3D"this.href=3D'javascript:';return true;" onclick=3D"this.href=3D'javasc=
ript:';return true;">anna.s...@gmail.com</a>&gt; wrote:<br type=3D"attribut=
ion"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bo=
rder-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:so=
lid;padding-left:1ex">


<div dir=3D"ltr"><span style=3D"font-family:arial,sans-serif">In the paper =
</span><a style=3D"font-family:arial,sans-serif" href=3D"https://isocpp.org=
/files/papers/N4078.html" target=3D"_blank" onmousedown=3D"this.href=3D'htt=
ps://www.google.com/url?q\75https%3A%2F%2Fisocpp.org%2Ffiles%2Fpapers%2FN40=
78.html\46sa\75D\46sntz\0751\46usg\75AFQjCNHCY0rGdgNwK1xSqCTZsz7l9ecf6g';re=
turn true;" onclick=3D"this.href=3D'https://www.google.com/url?q\75https%3A=
%2F%2Fisocpp.org%2Ffiles%2Fpapers%2FN4078.html\46sa\75D\46sntz\0751\46usg\7=
5AFQjCNHCY0rGdgNwK1xSqCTZsz7l9ecf6g';return true;">N4078</a><span style=3D"=
font-family:arial,sans-serif"> two Rvalue reference overloads was added to =
the optional&lt;T&gt; class:</span><br style=3D"font-family:arial,sans-seri=
f">


<code><span style=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-family:arial,sans-serif">&nbsp; constexpr T value() const&amp;&amp=
;</span><br style=3D"font-family:arial,sans-serif">


<span style=3D"font-family:arial,sans-serif">I think this overloads should =
return by r-value reference instead. <br></span></code><code><span style=3D=
"font-family:arial,sans-serif">&nbsp; constexpr T&amp;&amp; value() &amp;&a=
mp;;</span></code><br>


<code><span style=3D"font-family:arial,sans-serif"><br><b>I am not aware of=
 any other motivation for this change, please post if other one exists.</b>=
<br>Lets begin with the motivation for current desing. As far as I know thi=
s 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 referenc=
e if we would return by reference<br>I don think making this well-behaved m=
akes more harm that good. It adds single exceptional class<br>


int the langugage for which such code is well behaved. For example if we wr=
ite very similiar code<br>with a vector or std::tuple, this code wil still =
create a dangling reference.<br>&nbsp; std::vector&lt;std::string&gt; f();<=
br>


&nbsp; auto&amp;&amp; s =3D f.front(); //dangling reference<br>&nbsp; std::=
tuple&lt;std::string, exception_ptr&gt; g();<br>&nbsp; auto&amp;&amp; s =3D=
 get&lt;0&gt;(g()); //this is emulation of expected&lt;T&gt; or optional&lt=
;T&gt; with tuple<br>


So the standard library is not consistent with the behaviour, and even if w=
e fix every getter method<br>in the standard by adding rvalue overload, the=
 problem still won't be fixed without changing language<br>in case of the m=
embers:<br>


</span></code><code><span style=3D"font-family:arial,sans-serif">&nbsp; std=
::pair&lt;std::string, exception_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). This in my opinion mak=
es language more complicated<br>and leave the programmer with two options:<=
br>&nbsp; - remember this special case and apply them when possible<br>&nbs=
p; - ignore existence of this overloads<br>


<br>In addition the current desings introduces preformance impact on the co=
de. Let assume 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;&nbsp; This following two lines will =
now introduce additional move-construction o value of type T.<br>&nbsp;&nbs=
p; Someone may argue that this cost is not 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 course this<br>&nbsp;&n=
bsp; problem does not exists for tuple or pairs.<br>&nbsp;<br>In my opinion=
 it would be better to delcaret this functions as returning reference becau=
se it will make it consistent with rest of the language<br>


and by doing it will make it easier to use and understand.<br></span></code=
></div>

<p></p>

-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
jqJB6k03cWAJ" onmousedown=3D"this.href=3D'javascript:';return true;" onclic=
k=3D"this.href=3D'javascript:';return true;">std-proposal...@<wbr>isocpp.or=
g</a>.<br>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"jqJB6k03cWAJ" onmousedown=3D"this.href=3D'java=
script:';return true;" onclick=3D"this.href=3D'javascript:';return true;">s=
td-pr...@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank" onmousedown=3D"this.href=3D'http://groups=
..google.com/a/isocpp.org/group/std-proposals/';return true;" onclick=3D"thi=
s.href=3D'http://groups.google.com/a/isocpp.org/group/std-proposals/';retur=
n true;">http://groups.google.com/a/<wbr>isocpp.org/group/std-<wbr>proposal=
s/</a>.<br>
</blockquote></div>
</div>
</blockquote></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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_335_18890479.1404933714826--

.

On Wed, Jul 9, 2014 at 12:20 PM, Ville Voutilainen
<ville.voutilainen@gmail.com> wrote:
> On 9 July 2014 22:09, 'Jeffrey Yasskin' via ISO C++ Standard - Future
> Proposals <std-proposals@isocpp.org> wrote:
>> http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#1651 addresses:
>>
>>   std::pair<std::string, exception_ptr> g();
>>   auto&& s = g().first; //will create a dangling reference
>>
>> It's in 'ready' status, meaning it's not in C++14, but it's likely to get
>> fixed immediately after, possibly as a "defect", which would mean that most
>> compilers would implement the fix in their C++14 modes.
>>
>> I agree that I'd rather see the general issue fixed by a language change
>> (probably involving a change to the library to use the new language
>> feature). I'm ambivalent about the safety fix we have in optional<>.
>
>
> I think the "yes, moving twice is fine, but what if the move ends up
> copying?" issue
> and the "perfect-forwarding the underlying value from an optional
> becomes tricky"
> issue are worth discussing in LEWG. They certainly change my (minor) preference.

SGTM. Can you file a "NEEDS_DISCUSSION" issue on
https://issues.isocpp.org/? We'll also need an NB comment on the PDTS
if we're going to fix it for V1.

--

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

.

On 9 July 2014 22:22, 'Jeffrey Yasskin' via ISO C++ Standard - Future
Proposals <std-proposals@isocpp.org> wrote:
>> I think the "yes, moving twice is fine, but what if the move ends up
>> copying?" issue
>> and the "perfect-forwarding the underlying value from an optional
>> becomes tricky"
>> issue are worth discussing in LEWG. They certainly change my (minor) preference.
>
> SGTM. Can you file a "NEEDS_DISCUSSION" issue on
> https://issues.isocpp.org/? We'll also need an NB comment on the PDTS
> if we're going to fix it for V1.

Filed as
https://issues.isocpp.org/show_bug.cgi?id=45

The NB comment can also probably be arranged. ;)

--

---
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_490_4862776.1404935484685
Content-Type: text/plain; charset=UTF-8

After some thinking of the idea, I am not sure why it was choosen to
introduce a additional construction of the temporary to the .value() method
of the optional, even if we want to just:
 a) read the value passing opt.value() to function that takes the value
type by contt reference:
      optional<T> g();
      std::cout << g.value() << std::endl;
 * Ville I would like you to add this to the gut report, because
constructing a temporary to simply print a value may be overkill especially
if used in generic context with forward:*
  template<typename Nullable> //optional, smart_ptr
  void (Nullable&& nullable)
  {
     //do something
     f(*std::forward<Nullable>(nullable)); //does it make a temporary here,
or not??
  }
  b) construct another value from it:
      optional<T> g();
      auto opt = g();
To make the following code to work correclty:
     auto&& opt = g().value();
When it may be fixed by writing:
     auto opt = g().value();
and this will still invoke the same amount of construcotr as the above one,
because:
    auto&& opt = g().value(); is construction T from T&& and binding it to
reference
    auto opt = g(); is constructing T from T&& on stack

I start to think if the this auto&& everywhere recommendation that seems to
pop up form time to time is actually a good design guide.


--

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

<div dir=3D"ltr">After some thinking of the idea, I am not sure why it was =
choosen to introduce a additional construction of the temporary to the .val=
ue() method of the optional, even if we want to just:<br>&nbsp;a) read the =
value passing opt.value() to function that takes the value type by contt re=
ference:<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; optional&lt;T&gt; g();<br>&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp; std::cout &lt;&lt; g.value() &lt;&lt; std::endl;<b=
r>&nbsp;<b> Ville I would like you to add this to the gut report, because c=
onstructing a temporary to simply print a value may be overkill especially =
if used in generic context with forward:</b><br>&nbsp; template&lt;typename=
 Nullable&gt; //optional, smart_ptr<br>&nbsp; void (Nullable&amp;&amp; null=
able)<br>&nbsp; {<br>&nbsp;&nbsp;&nbsp;&nbsp; //do something<br>&nbsp;&nbsp=
;&nbsp;&nbsp; f(*std::forward&lt;Nullable&gt;(nullable)); //does it make a =
temporary here, or not??<br>&nbsp; }<br>&nbsp; b) construct another value f=
rom it:<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; optional&lt;T&gt; g();<br>&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp; auto opt =3D g();<br>To make the following code to =
work correclty:<br>&nbsp;&nbsp;&nbsp;&nbsp; auto&amp;&amp; opt =3D g().valu=
e();<br>When it may be fixed by writing:<br>&nbsp;&nbsp;&nbsp;&nbsp; auto o=
pt =3D g().value();<br>and this will still invoke the same amount of constr=
ucotr as the above one, because:<br>&nbsp;&nbsp;&nbsp; auto&amp;&amp; opt =
=3D g().value(); is construction T from T&amp;&amp; and binding it to refer=
ence<br>&nbsp;&nbsp;&nbsp; auto opt =3D g(); is constructing T from T&amp;&=
amp; on stack<br><br>I start to think if the this auto&amp;&amp; everywhere=
 recommendation that seems to pop up form time to time is actually a good d=
esign guide.<br>&nbsp;&nbsp; <br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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_490_4862776.1404935484685--

.

On 9 July 2014 22:51,  <tomaszkam@gmail.com> wrote:
> After some thinking of the idea, I am not sure why it was choosen to
> introduce a additional construction of the temporary to the .value() method
> of the optional, even if we want to just:
>  a) read the value passing opt.value() to function that takes the value type
> by contt reference:
>       optional<T> g();
>       std::cout << g.value() << std::endl;
>   Ville I would like you to add this to the gut report, because constructing
> a temporary to simply print a value may be overkill especially if used in
> generic context with forward:

I added a link to this message of yours to the bug report.

> I start to think if the this auto&& everywhere recommendation that seems to
> pop up form time to time is actually a good design guide.


Here's a moderate suggestion: NO, that recommendation is
brain-dama^W^Wunwise. :)

Using auto everywhere is not necessarily a good idea. Using auto&& everywhere is
no worse or better than using auto everywhere in general. Use auto wisely, and
when you don't want the target type to change without noticing it,
don't use it. When
you're ok with types changing, use it. Don't use it just to save
typing UNLESS you're
confident that the types don't change in uncontrolled ways - that is,
if you get a Container
in, feel free to use auto with Container::begin, but don't use it with
whatever expressions
unless you have a generic concept that is enforced via other means, or
you're certain
that you don't care about the type.

Don't just blindly sprinkle auto (or auto&&) all over code just
because it's nice and short.

--

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

.

On Wednesday 09 July 2014 12:09:14 'Jeffrey Yasskin' via ISO C++ Standard -
Future Proposals wrote:
>   std::pair<std::string, exception_ptr> g();
>   auto&& s = g().first; //will create a dangling reference

If you were to use auto or decltype(auto), the problem would go away, wouldn't
it?

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--

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

.

On 9 July 2014 23:03, Thiago Macieira <thiago@macieira.org> wrote:
> On Wednesday 09 July 2014 12:09:14 'Jeffrey Yasskin' via ISO C++ Standard -
> Future Proposals wrote:
>>   std::pair<std::string, exception_ptr> g();
>>   auto&& s = g().first; //will create a dangling reference
>
> If you were to use auto or decltype(auto), the problem would go away, wouldn't
> it?


Some problems would, but some problems wouldn't. You may have an lvalue
optional and you don't want to get a copy of the underlying value in that case.
decltype(auto) will not help if the function returns an rvalue reference, since
that would be the type of decltype(auto), too, right?

--

---
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_667_18983488.1404936797010
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Actually every code that looks loke
{
  auto&& cs =3D f();
  /* do something */
}

May be changed to:
template<typename T>
void helper(T&& t)
{
    /* do something */
}
helper(f());

Or even:
[&](auto&& cs) {
    /* do something */
} (f());

And actually fix every dangling reference problem that could occur with=20
original code aut&& cs =3D f(), because result of f will be destoryed after=
=20
the functor invocation,

W dniu =C5=9Broda, 9 lipca 2014 22:03:13 UTC+2 u=C5=BCytkownik Thiago Macie=
ira=20
napisa=C5=82:
>
> On Wednesday 09 July 2014 12:09:14 'Jeffrey Yasskin' via ISO C++ Standard=
=20
> -=20
> Future Proposals wrote:=20
> >   std::pair<std::string, exception_ptr> g();=20
> >   auto&& s =3D g().first; //will create a dangling reference=20
>
> If you were to use auto or decltype(auto), the problem would go away,=20
> wouldn't=20
> it?=20
>
> Yes but wont fix:
  std::pair<std::string, exception_ptr> g();=20
  auto&& s=3D std::get<0>(g);

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

<div dir=3D"ltr">Actually every code that looks loke<br>{<br>&nbsp; auto&am=
p;&amp; cs =3D f();<br>&nbsp; /* do something */<br>}<br><br>May be changed=
 to:<br>template&lt;typename T&gt;<br>void helper(T&amp;&amp; t)<br>{<br>&n=
bsp; &nbsp; /* do something */<br>}<br>helper(f());<br><br>Or even:<br>[&am=
p;](auto&amp;&amp; cs) {<br>&nbsp; &nbsp; /* do something */<br>} (f());<br=
><br>And actually fix every dangling reference problem that could occur wit=
h original code aut&amp;&amp; cs =3D f(), because result of f will be desto=
ryed after the functor invocation,<br><br>W dniu =C5=9Broda, 9 lipca 2014 2=
2:03:13 UTC+2 u=C5=BCytkownik Thiago Macieira napisa=C5=82:<blockquote clas=
s=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #c=
cc solid;padding-left: 1ex;">On Wednesday 09 July 2014 12:09:14 'Jeffrey Ya=
sskin' via ISO C++ Standard -=20
<br>Future Proposals wrote:
<br>&gt; &nbsp; std::pair&lt;std::string, exception_ptr&gt; g();
<br>&gt; &nbsp; auto&amp;&amp; s =3D g().first; //will create a dangling re=
ference
<br>
<br>If you were to use auto or decltype(auto), the problem would go away, w=
ouldn't=20
<br>it?
<br>
<br></blockquote><div>Yes but wont fix:<br>&nbsp; std::pair&lt;std::string,=
 exception_ptr&gt; g();
<br>&nbsp;  auto&amp;&amp; s=3D std::get&lt;0&gt;(g);<br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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_667_18983488.1404936797010--

.

------=_Part_486_351318.1404937450926
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

W dniu =C5=9Broda, 9 lipca 2014 22:13:17 UTC+2 u=C5=BCytkownik toma...@gmai=
l.com=20
napisa=C5=82:
>
> Actually every code that looks loke
> {
>   auto&& cs =3D f();
>   /* do something */
> }
>
> May be changed to:
> template<typename T>
> void helper(T&& t)
> {
>     /* do something */
> }
> helper(f());
>
> Or even:
> [&](auto&& cs) {
>     /* do something */
> } (f());
>
>  Using the SCOPE_GUARD trick, even the following pseudo-statement syntax=
=20
would be possible:
LET(cs, f()) { /* do something */ }
See: http://goo.gl/lTUSj7

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

<div dir=3D"ltr">W dniu =C5=9Broda, 9 lipca 2014 22:13:17 UTC+2 u=C5=BCytko=
wnik toma...@gmail.com napisa=C5=82:<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">Actually every code that looks loke<br>{<br>&nbsp; a=
uto&amp;&amp; cs =3D f();<br>&nbsp; /* do something */<br>}<br><br>May be c=
hanged to:<br>template&lt;typename T&gt;<br>void helper(T&amp;&amp; t)<br>{=
<br>&nbsp; &nbsp; /* do something */<br>}<br>helper(f());<br><br>Or even:<b=
r>[&amp;](auto&amp;&amp; cs) {<br>&nbsp; &nbsp; /* do something */<br>} (f(=
));<br><br></div></blockquote><div>&nbsp;Using the SCOPE_GUARD trick, even =
the following pseudo-statement syntax would be possible:<br>LET(cs, f()) { =
 /* do something */ }<br>See: http://goo.gl/lTUSj7<br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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_486_351318.1404937450926--

.

------=_Part_32_17200061.1404937529782
Content-Type: text/plain; charset=UTF-8

FWIW, I agree with the point made that fixing single case of dangling
reference from "optional<R>::value() &&" while sacrificing performance and
(more importantly) library consistency is not worth it. Personally I would
prefer if value() && overload returned rvalue-reference rather than value.
Also, while move-constructors are very mean to be cheap, they are actually
not free. Memory of the original object needs to be touched (to take away
ownership of data) which is more expensive that doing nothing.

--

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

<div dir=3D"ltr"><div>FWIW, I agree with the point made that fixing single =
case of dangling reference from "optional&lt;R&gt;::value() &amp;&amp;" whi=
le sacrificing performance and (more importantly) library consistency is no=
t worth it. Personally I would prefer if value() &amp;&amp; overload return=
ed rvalue-reference rather than value. Also, while move-constructors are ve=
ry mean to be cheap, they are actually not free. Memory of the original obj=
ect needs to be touched (to take away ownership of data) which is more expe=
nsive that doing nothing.</div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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_32_17200061.1404937529782--

.

--089e0122f2aadf1b2704fdc8d40b
Content-Type: text/plain; charset=UTF-8

On 9 July 2014 15:25, <b.kozicki@gmail.com> wrote:

> FWIW, I agree with the point made that fixing single case of dangling
> reference from "optional<R>::value() &&" while sacrificing performance and
> (more importantly) library consistency is not worth it. Personally I would
> prefer if value() && overload returned rvalue-reference rather than value.
>

Personally, I would prefer that a function we call value() actually return
something by value.  But I suppose that is part of a different discussion,
since it doesn't now...
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404

--

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

--089e0122f2aadf1b2704fdc8d40b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On 9 July 2014 15:25,  <span dir=3D"ltr">&lt;<a href=3D"ma=
ilto:b.kozicki@gmail.com" target=3D"_blank">b.kozicki@gmail.com</a>&gt;</sp=
an> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blockq=
uote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex">

<div dir=3D"ltr"><div>FWIW, I agree with the point made that fixing single =
case of dangling reference from &quot;optional&lt;R&gt;::value() &amp;&amp;=
&quot; while sacrificing performance and (more importantly) library consist=
ency is not worth it. Personally I would prefer if value() &amp;&amp; overl=
oad returned rvalue-reference rather than value. </div>

</div></blockquote><div><br></div><div>Personally, I would prefer that a fu=
nction we call value() actually return something by value. =C2=A0But I supp=
ose that is part of a different discussion, since it doesn&#39;t now...</di=
v>

</div>-- <br>=C2=A0Nevin &quot;:-)&quot; Liber=C2=A0 &lt;mailto:<a href=3D"=
mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>=
&gt;=C2=A0 (847) 691-1404
</div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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 />

--089e0122f2aadf1b2704fdc8d40b--

.

--Apple-Mail=_D3F29849-7729-4AB5-8D95-1B236BB8ADE0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1


On 2014-07-10, at 3:09 AM, 'Jeffrey Yasskin' via ISO C++ Standard - Future =
Proposals <std-proposals@isocpp.org> wrote:

> http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#1651 addresse=
s:
>=20
>   std::pair<std::string, exception_ptr> g();
>   auto&& s =3D g().first; //will create a dangling reference
>=20
> It's in 'ready' status, meaning it's not in C++14, but it's likely to get=
 fixed immediately after, possibly as a "defect", which would mean that mos=
t compilers would implement the fix in their C++14 modes.
>=20


This is already fixed in GCC and Clang in C++11 mode. Defect reports are us=
ually applied asynchronously. However, GCC has a lingering bug where a refe=
rence bound to a scalar member will not extend the lifetime of a class obje=
ct. (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D60297)

Of course binding a reference to a subobject extends the complete object. W=
hat else do you want, destruction of the rest of the object *except* the su=
bobject??

Sorry for replying to a message earlier in the thread, but the subsequent m=
essages here made me extremely confused, because they are dealing with a hy=
pothetical that seems already to have been prevented.

auto && has some strong proponents, and although nothing is a silver bullet=
, it will always work except when a function returns an rvalue reference --=
 which, as the title of this thread and most of the early messages indicate=
, is a problem to be fixed.

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

--Apple-Mail=_D3F29849-7729-4AB5-8D95-1B236BB8ADE0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014&=
ndash;07&ndash;10, at 3:09 AM, 'Jeffrey Yasskin' via ISO C++ Standard - Fut=
ure Proposals &lt;<a href=3D"mailto:std-proposals@isocpp.org">std-proposals=
@isocpp.org</a>&gt; wrote:</div><br class=3D"Apple-interchange-newline"><bl=
ockquote type=3D"cite"><div dir=3D"ltr"><p dir=3D"ltr"><a href=3D"http://ww=
w.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#1651">http://www.open-st=
d.org/jtc1/sc22/wg21/docs/cwg_active.html#1651</a> addresses:</p><p dir=3D"=
ltr"><span style=3D"font-family:arial,sans-serif">&nbsp; std::pair&lt;std::=
string, exception_ptr&gt; g();</span><br style=3D"font-family:arial,sans-se=
rif">

<span style=3D"font-family:arial,sans-serif">&nbsp; auto&amp;&amp; s =3D g(=
).first; //will create a dangling reference</span><br></p><p>It's in 'ready=
' status, meaning it's not in C++14, but it's likely to get fixed immediate=
ly after, possibly as a "defect", which would mean that most compilers woul=
d implement the fix in their C++14 modes.</p></div></blockquote></div><div>=
<br></div><div>This is already fixed in GCC and Clang in C++11 mode. Defect=
 reports are usually applied asynchronously. However, GCC has a lingering b=
ug where a reference bound to a scalar member will not extend the lifetime =
of a class object. (<a href=3D"https://gcc.gnu.org/bugzilla/show_bug.cgi?id=
=3D60297">https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D60297</a>)</div><d=
iv><br></div><div>Of course binding a reference to a subobject extends the =
complete object. What else do you want, destruction of the rest of the obje=
ct *<i>except</i>* the subobject??</div><div><br></div><div>Sorry for reply=
ing to a message earlier in the thread, but the subsequent messages here ma=
de me extremely confused, because they are dealing with a hypothetical that=
 seems already to have been prevented.</div><div><br></div><div><font face=
=3D"Courier">auto &amp;&amp;</font> has some strong proponents, and althoug=
h nothing is a silver bullet, it will always work except when a function re=
turns an rvalue reference &mdash; which, as the title of this thread and mo=
st of the early messages indicate, is a problem to be fixed.</div><div><br>=
</div></body></html>

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

--Apple-Mail=_D3F29849-7729-4AB5-8D95-1B236BB8ADE0--

.

------=_Part_1782_32662766.1404969107853
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



W dniu czwartek, 10 lipca 2014 01:17:39 UTC+2 u=C5=BCytkownik David Krauss=
=20
napisa=C5=82:
>
>
> On 2014=E2=80=9307=E2=80=9310, at 3:09 AM, 'Jeffrey Yasskin' via ISO C++ =
Standard - Future=20
> Proposals <std-pr...@isocpp.org <javascript:>> wrote:
>
> http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#1651=20
> addresses:
>
>   std::pair<std::string, exception_ptr> g();
>   auto&& s =3D g().first; //will create a dangling reference
>
> It's in 'ready' status, meaning it's not in C++14, but it's likely to get=
=20
> fixed immediately after, possibly as a "defect", which would mean that mo=
st=20
> compilers would implement the fix in their C++14 modes.
>
>
> This is already fixed in GCC and Clang in C++11 mode. Defect reports are=
=20
> usually applied asynchronously. However, GCC has a lingering bug where a=
=20
> reference bound to a scalar member will not extend the lifetime of a clas=
s=20
> object. (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D60297)
>
> Of course binding a reference to a subobject extends the complete object.=
=20
> What else do you want, destruction of the rest of the object **except**=
=20
> the subobject??
>
> Sorry for replying to a message earlier in the thread, but the subsequent=
=20
> messages here made me extremely confused, because they are dealing with a=
=20
> hypothetical that seems already to have been prevented.
>
> auto && has some strong proponents, and although nothing is a silver=20
> bullet, it will always work except when a function returns an rvalue=20
> reference =E2=80=94 which, as the title of this thread and most of the ea=
rly=20
> messages indicate, is a problem to be fixed.
>
No, the auto&& does not work with any function that return a any kind of=20
reference to subobject of it parameter (including this) is invoked on an=20
rvalue. In the examples above you my find:
std::vector<std::string> f();
auto&& s =3D f.front();
//This creates a dangling lvalue reference, and front() has not r-value=20
overloads.

The whole discussion is about that the changes was made to the optional<T>=
=20
that makes following work correctly in cost on introducing temporaries in=
=20
other places:
std::optional<T> g();
auto&& s =3D g().value();


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

<div dir=3D"ltr"><br><br>W dniu czwartek, 10 lipca 2014 01:17:39 UTC+2 u=C5=
=BCytkownik David Krauss napisa=C5=82:<blockquote class=3D"gmail_quote" sty=
le=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left=
: 1ex;"><div style=3D"word-wrap:break-word"><br><div><div>On 2014=E2=80=930=
7=E2=80=9310, at 3:09 AM, 'Jeffrey Yasskin' via ISO C++ Standard - Future P=
roposals &lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailt=
o=3D"HLQFuTVf1joJ" onmousedown=3D"this.href=3D'javascript:';return true;" o=
nclick=3D"this.href=3D'javascript:';return true;">std-pr...@isocpp.org</a>&=
gt; wrote:</div><br><blockquote type=3D"cite"><div dir=3D"ltr"><p dir=3D"lt=
r"><a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#1=
651" target=3D"_blank" onmousedown=3D"this.href=3D'http://www.google.com/ur=
l?q\75http%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fcwg_activ=
e.html%231651\46sa\75D\46sntz\0751\46usg\75AFQjCNHVoie10PZYFxvkX-eVFGjeRad_=
GQ';return true;" onclick=3D"this.href=3D'http://www.google.com/url?q\75htt=
p%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fcwg_active.html%23=
1651\46sa\75D\46sntz\0751\46usg\75AFQjCNHVoie10PZYFxvkX-eVFGjeRad_GQ';retur=
n true;">http://www.open-std.org/jtc1/<wbr>sc22/wg21/docs/cwg_active.<wbr>h=
tml#1651</a> addresses:</p><p dir=3D"ltr"><span style=3D"font-family:arial,=
sans-serif">&nbsp; std::pair&lt;std::string, exception_ptr&gt; g();</span><=
br style=3D"font-family:arial,sans-serif">

<span style=3D"font-family:arial,sans-serif">&nbsp; auto&amp;&amp; s =3D g(=
).first; //will create a dangling reference</span><br></p><p>It's in 'ready=
' status, meaning it's not in C++14, but it's likely to get fixed immediate=
ly after, possibly as a "defect", which would mean that most compilers woul=
d implement the fix in their C++14 modes.</p></div></blockquote></div><div>=
<br></div><div>This is already fixed in GCC and Clang in C++11 mode. Defect=
 reports are usually applied asynchronously. However, GCC has a lingering b=
ug where a reference bound to a scalar member will not extend the lifetime =
of a class object. (<a href=3D"https://gcc.gnu.org/bugzilla/show_bug.cgi?id=
=3D60297" target=3D"_blank" onmousedown=3D"this.href=3D'https://www.google.=
com/url?q\75https%3A%2F%2Fgcc.gnu.org%2Fbugzilla%2Fshow_bug.cgi%3Fid%3D6029=
7\46sa\75D\46sntz\0751\46usg\75AFQjCNHOdhHk8U2_uaVtVedT4W4EXF03Xw';return t=
rue;" onclick=3D"this.href=3D'https://www.google.com/url?q\75https%3A%2F%2F=
gcc.gnu.org%2Fbugzilla%2Fshow_bug.cgi%3Fid%3D60297\46sa\75D\46sntz\0751\46u=
sg\75AFQjCNHOdhHk8U2_uaVtVedT4W4EXF03Xw';return true;">https://gcc.gnu.org/=
bugzilla/<wbr>show_bug.cgi?id=3D60297</a>)</div><div><br></div><div>Of cour=
se binding a reference to a subobject extends the complete object. What els=
e do you want, destruction of the rest of the object *<i>except</i>* the su=
bobject??</div><div><br></div><div>Sorry for replying to a message earlier =
in the thread, but the subsequent messages here made me extremely confused,=
 because they are dealing with a hypothetical that seems already to have be=
en prevented.</div><div><br></div><div><font face=3D"Courier">auto &amp;&am=
p;</font> has some strong proponents, and although nothing is a silver bull=
et, it will always work except when a function returns an rvalue reference =
=E2=80=94 which, as the title of this thread and most of the early messages=
 indicate, is a problem to be fixed.</div></div></blockquote><div>No, the a=
uto&amp;&amp; does not work with any function that return a any kind of ref=
erence to subobject of it parameter (including this) is invoked on an rvalu=
e. In the examples above you my find:<br>std::vector&lt;std::string&gt; f()=
;<br>auto&amp;&amp; s =3D f.front();<br>//This creates a dangling lvalue re=
ference, and front() has not r-value overloads.<br><br>The whole discussion=
 is about that the changes was made to the optional&lt;T&gt; that makes fol=
lowing work correctly in cost on introducing temporaries in other places:<b=
r>std::optional&lt;T&gt; g();<br>auto&amp;&amp; s =3D g().value();<br><br><=
br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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_1782_32662766.1404969107853--

.

--Apple-Mail=_A330A76D-647A-412A-B8F6-CB5E58257283
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8


On 2014=E2=80=9307=E2=80=9310, at 1:11 PM, tomaszkam@gmail.com wrote:

> W dniu czwartek, 10 lipca 2014 01:17:39 UTC+2 u=C5=BCytkownik David Kraus=
s napisa=C5=82:
>=20
> auto && has some strong proponents, and although nothing is a silver bull=
et, it will always work except when a function returns an rvalue reference =
=E2=80=94 which, as the title of this thread and most of the early messages=
 indicate, is a problem to be fixed.

> No, the auto&& does not work with any function that return a any kind of =
reference to subobject of it parameter (including this) is invoked on an rv=
alue. In the examples above you my find:
> std::vector<std::string> f();
> auto&& s =3D f.front();
> //This creates a dangling lvalue reference, and front() has not r-value o=
verloads.

I think you mean f().front(). As per this thread, or maybe it=E2=80=99s jus=
t my extrapolation, the solution is to add an rvalue-ref qualified overload=
 returning by value.

As a very general policy in C++ library design, every accessor to a strictl=
y owned resource should be lvalue-qualified and/or return by value. This be=
st practice should be applied across the standard library.

> The whole discussion is about that the changes was made to the optional<T=
> that makes following work correctly in cost on introducing temporaries in=
 other places:

Whether returning a direct member or something owned elsewhere, methods of =
an xvalue should always return by value. If a temporary might be introduced=
 elsewhere, correctness is always worth the cost =E2=80=94 and copy elision=
 will probably eliminate it anyway.

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

--Apple-Mail=_A330A76D-647A-412A-B8F6-CB5E58257283
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;"><br><div><div>On 2014=E2=80=
=9307=E2=80=9310, at 1:11 PM, <a href=3D"mailto:tomaszkam@gmail.com">tomasz=
kam@gmail.com</a> wrote:</div><br><blockquote type=3D"cite"><div dir=3D"ltr=
">W dniu czwartek, 10 lipca 2014 01:17:39 UTC+2 u=C5=BCytkownik David Kraus=
s napisa=C5=82:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0=
px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); bo=
rder-left-style: solid; padding-left: 1ex; position: static; z-index: auto;=
"><div style=3D"word-wrap:break-word"><br><div><div><font face=3D"Courier">=
auto &amp;&amp;</font> has some strong proponents, and although nothing is =
a silver bullet, it will always work except when a function returns an rval=
ue reference =E2=80=94 which, as the title of this thread and most of the e=
arly messages indicate, is a problem to be fixed.</div></div></div></blockq=
uote></div></blockquote><br><blockquote type=3D"cite"><div dir=3D"ltr"><div=
>No, the auto&amp;&amp; does not work with any function that return a any k=
ind of reference to subobject of it parameter (including this) is invoked o=
n an rvalue. In the examples above you my find:<br>std::vector&lt;std::stri=
ng&gt; f();<br>auto&amp;&amp; s =3D f.front();<br>//This creates a dangling=
 lvalue reference, and front() has not r-value overloads.<br></div></div></=
blockquote><div><br></div><div>I think you mean <font face=3D"Courier">f().=
front()</font>. As per this thread, or maybe it=E2=80=99s just my extrapola=
tion, the solution is to add an rvalue-ref qualified overload returning by =
value.</div><div><br></div><div>As a very general policy in C++ library des=
ign, every accessor to a strictly owned resource should be lvalue-qualified=
 and/or return by value. This best practice should be applied across the st=
andard library.</div><div><br></div><blockquote type=3D"cite"><div dir=3D"l=
tr"><div>The whole discussion is about that the changes was made to the opt=
ional&lt;T&gt; that makes following work correctly in cost on introducing t=
emporaries in other places:<br></div></div></blockquote><div><br></div></di=
v>Whether returning a direct member or something owned elsewhere, methods o=
f an xvalue should always return by value. If a temporary might be introduc=
ed elsewhere, correctness is always worth&nbsp;the cost&nbsp;=E2=80=94 and =
copy elision will probably eliminate it anyway.<div><br></div></body></html=
>

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

--Apple-Mail=_A330A76D-647A-412A-B8F6-CB5E58257283--

.

On 10 July 2014 08:48, David Krauss <potswa@gmail.com> wrote:
>
> On 2014=E2=80=9307=E2=80=9310, at 1:11 PM, tomaszkam@gmail.com wrote:
> No, the auto&& does not work with any function that return a any kind of
> reference to subobject of it parameter (including this) is invoked on an
> rvalue. In the examples above you my find:
> std::vector<std::string> f();
> auto&& s =3D f.front();
> //This creates a dangling lvalue reference, and front() has not r-value
> overloads.
>
>
> I think you mean f().front(). As per this thread, or maybe it=E2=80=99s j=
ust my
> extrapolation, the solution is to add an rvalue-ref qualified overload
> returning by value.

The solution, as per this thread, is to not use auto&& for such cases.

> As a very general policy in C++ library design, every accessor to a stric=
tly
> owned resource should be lvalue-qualified and/or return by value. This be=
st
> practice should be applied across the standard library.

I fail to see how that is "best practice".

>
> The whole discussion is about that the changes was made to the optional<T=
>
> that makes following work correctly in cost on introducing temporaries in
> other places:
>
>
> Whether returning a direct member or something owned elsewhere, methods o=
f
> an xvalue should always return by value. If a temporary might be introduc=
ed
> elsewhere, correctness is always worth the cost =E2=80=94 and copy elisio=
n will
> probably eliminate it anyway.


Except that copy elision will not eliminate it, and this correctness
is not worth
the cost.

--=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_25_2047126.1404972618835
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


W dniu czwartek, 10 lipca 2014 07:48:29 UTC+2 u=C5=BCytkownik David Krauss=
=20
napisa=C5=82:
>
>
> On 2014=E2=80=9307=E2=80=9310, at 1:11 PM, toma...@gmail.com <javascript:=
> wrote:
>
> W dniu czwartek, 10 lipca 2014 01:17:39 UTC+2 u=C5=BCytkownik David Kraus=
s=20
> napisa=C5=82:
>>
>>
>> auto && has some strong proponents, and although nothing is a silver=20
>> bullet, it will always work except when a function returns an rvalue=20
>> reference =E2=80=94 which, as the title of this thread and most of the e=
arly=20
>> messages indicate, is a problem to be fixed.
>>
>
> No, the auto&& does not work with any function that return a any kind of=
=20
> reference to subobject of it parameter (including this) is invoked on an=
=20
> rvalue. In the examples above you my find:
> std::vector<std::string> f();
> auto&& s =3D f.front();
> //This creates a dangling lvalue reference, and front() has not r-value=
=20
> overloads.
>
>
> I think you mean f().front(). As per this thread, or maybe it=E2=80=99s j=
ust my=20
> extrapolation, the solution is to add an rvalue-ref qualified overload=20
> returning by value.
>
> As a very general policy in C++ library design, every accessor to a=20
> strictly owned resource should be lvalue-qualified and/or return by value=
..=20
> This best practice should be applied across the standard library.
>
> And dou you expect the following to also work (example presented above): =
 =20
      auto&& s =3D *f.begin();

In addition: "Of course binding a reference to a subobject extends the=20
complete object. What else do you want, destruction of the rest of the=20
object **except** the subobject??"
Llets assume following scenario:
struct Result
{
    std::string array[100];
    std::string& best; //best points to one element of array, making it by=
=20
reference stop at least assigment
};=20

//Lets assume that the following class returns array of 100 elements and=20
hint for the best element
Result foo();

//Then you would like the following to work
auto&& cs =3D foo().best;

But then let assume we have another class:
struct Result
{
    std::string array[100];
    std::string const& something; //this is reference to some managed=20
otherwise class
};=20

Result get();

And we have following code that works in C++98 and jsut ignores content of=
=20
array:
const std::string& some =3D get().something;
Now with prpopsed change this code will also store arrays of 100 elements=
=20
in every stack trace. Then this may lead to stack overflow in arleady=20
existing codebase.
And what if instead of array in the result we have some class that for=20
example managers resources, then extending if liftime may silently change=
=20
behaviour of existing code, even if there was no
dangling reference beffore. Lets imange some kind of unique_lock there and=
=20
silently introduced deadlock by change of the compiler.

//If you argue that reference should be a special case, please consider=20
mameber taht mdoesl reference wrapper instead of reference direclty.

Please stop this make "auto&&" movment, becuase it is now going insea with=
=20
breaking existing code, to make this single statment work. The problem lies=
=20
in usign the extension of temporaries by binding in block scope.

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

<div dir=3D"ltr"><br>W dniu czwartek, 10 lipca 2014 07:48:29 UTC+2 u=C5=BCy=
tkownik David Krauss napisa=C5=82:<blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;"><div style=3D"word-wrap:break-word"><br><div><div>On 2014=E2=80=9307=
=E2=80=9310, at 1:11 PM, <a href=3D"javascript:" target=3D"_blank" gdf-obfu=
scated-mailto=3D"2_2y_Hm6SEcJ" onmousedown=3D"this.href=3D'javascript:';ret=
urn true;" onclick=3D"this.href=3D'javascript:';return true;">toma...@gmail=
..com</a> wrote:</div><br><blockquote type=3D"cite"><div dir=3D"ltr">W dniu =
czwartek, 10 lipca 2014 01:17:39 UTC+2 u=C5=BCytkownik David Krauss napisa=
=C5=82:<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;=
border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:=
solid;padding-left:1ex"><div style=3D"word-wrap:break-word"><br><div><div><=
font face=3D"Courier">auto &amp;&amp;</font> has some strong proponents, an=
d although nothing is a silver bullet, it will always work except when a fu=
nction returns an rvalue reference =E2=80=94 which, as the title of this th=
read and most of the early messages indicate, is a problem to be fixed.</di=
v></div></div></blockquote></div></blockquote><br><blockquote type=3D"cite"=
><div dir=3D"ltr"><div>No, the auto&amp;&amp; does not work with any functi=
on that return a any kind of reference to subobject of it parameter (includ=
ing this) is invoked on an rvalue. In the examples above you my find:<br>st=
d::vector&lt;std::string&gt; f();<br>auto&amp;&amp; s =3D f.front();<br>//T=
his creates a dangling lvalue reference, and front() has not r-value overlo=
ads.<br></div></div></blockquote><div><br></div><div>I think you mean <font=
 face=3D"Courier">f().front()</font>. As per this thread, or maybe it=E2=80=
=99s just my extrapolation, the solution is to add an rvalue-ref qualified =
overload returning by value.</div><div><br></div><div>As a very general pol=
icy in C++ library design, every accessor to a strictly owned resource shou=
ld be lvalue-qualified and/or return by value. This best practice should be=
 applied across the standard library.</div><div><br></div></div></div></blo=
ckquote><div>And dou you expect the following to also work (example present=
ed above):&nbsp;&nbsp; <br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; auto&amp;&amp; s =
=3D *f.begin();<br><br>In addition: "Of course binding a reference to a sub=
object extends
 the complete object. What else do you want, destruction of the rest of=20
the object *<i>except</i>* the subobject??"<br>Llets assume following scena=
rio:<br>struct Result<br>{<br>&nbsp;&nbsp;&nbsp; std::string array[100];<br=
>&nbsp;&nbsp;&nbsp; std::string&amp; best; //best points to one element of =
array, making it by reference stop at least assigment<br>}; <br><br>//Lets =
assume that the following class returns array of 100 elements and hint for =
the best element<br>Result foo();<br><br>//Then you would like the followin=
g to work<br>auto&amp;&amp; cs =3D foo().best;<br><br>But then let assume w=
e have another class:<br>struct Result<br>{<br>&nbsp;&nbsp;&nbsp; std::stri=
ng array[100];<br>&nbsp;&nbsp;&nbsp; std::string const&amp; something; //th=
is is reference to some managed otherwise class<br>}; <br><br> Result get()=
;<br><br>And we have following code that works in C++98 and jsut ignores co=
ntent of array:<br>const std::string&amp; some =3D get().something;<br>Now =
with prpopsed change this code will also store arrays of 100 elements in ev=
ery stack trace. Then this may lead to stack overflow in arleady existing c=
odebase.<br>And what if instead of array in the result we have some class t=
hat for example managers resources, then extending if liftime may silently =
change behaviour of existing code, even if there was no<br>dangling referen=
ce beffore. Lets imange some kind of unique_lock there and silently introdu=
ced deadlock by change of the compiler.<br><br>//If you argue that referenc=
e should be a special case, please consider mameber taht mdoesl reference w=
rapper instead of reference direclty.<br><br>Please stop this make "auto&am=
p;&amp;" movment, becuase it is now going insea with breaking existing code=
, to make this single statment work. The problem lies in usign the extensio=
n of temporaries by binding in block scope.<br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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_25_2047126.1404972618835--

.

--Apple-Mail=_5D3D7484-C4AA-4437-8142-084D173768DC
Content-Type: text/plain; charset=ISO-8859-1


On 2014-07-10, at 2:04 PM, Ville Voutilainen <ville.voutilainen@gmail.com> wrote:

>> As a very general policy in C++ library design, every accessor to a strictly
>> owned resource should be lvalue-qualified and/or return by value. This best
>> practice should be applied across the standard library.
>
> I fail to see how that is "best practice".

The resource is strictly owned and the owner is represented by an xvalue. Therefore the resource will be going away very soon. It would be incorrect to return a reference to it.

Returning by rvalue reference may be tempting, but that is the semantic of move(). It does not transfer ownership, it only provides the caller with a handle to accept ownership. Returning an rvalue reference is something only special functions should do.

>> Whether returning a direct member or something owned elsewhere, methods of
>> an xvalue should always return by value. If a temporary might be introduced
>> elsewhere, correctness is always worth the cost -- and copy elision will
>> probably eliminate it anyway.
>
> Except that copy elision will not eliminate it, and this correctness
> is not worth
> the cost.

Then perhaps we need more cases for copy elision. Sneaky rvalue reference hacks will only provide surprises and make user code more brittle. If there must be an rvalue reference overload, it should be named move_value() to indicate the different semantic.

--

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

--Apple-Mail=_5D3D7484-C4AA-4437-8142-084D173768DC
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014&=
ndash;07&ndash;10, at 2:04 PM, Ville Voutilainen &lt;<a href=3D"mailto:vill=
e.voutilainen@gmail.com">ville.voutilainen@gmail.com</a>&gt; wrote:</div><b=
r><blockquote type=3D"cite"><blockquote type=3D"cite">As a very general pol=
icy in C++ library design, every accessor to a strictly<br>owned resource s=
hould be lvalue-qualified and/or return by value. This best<br>practice sho=
uld be applied across the standard library.<br></blockquote><br>I fail to s=
ee how that is "best practice&rdquo;.<br></blockquote><div><br></div><div>T=
he resource is strictly owned and the owner is represented by an xvalue. Th=
erefore the resource will be going away very soon. It would be incorrect to=
 return a reference to it.</div><div><br></div><div>Returning by rvalue ref=
erence may be tempting, but that is the semantic of move(). It does not tra=
nsfer ownership, it only provides the caller with a handle to accept owners=
hip. Returning an rvalue reference is something only special functions shou=
ld do.</div><br><blockquote type=3D"cite"><blockquote type=3D"cite">Whether=
 returning a direct member or something owned elsewhere, methods of<br>an x=
value should always return by value. If a temporary might be introduced<br>=
elsewhere, correctness is always worth the cost &mdash; and copy elision wi=
ll<br>probably eliminate it anyway.<br></blockquote><br>Except that copy el=
ision will not eliminate it, and this correctness<br>is not worth<br>the co=
st.<br></blockquote></div><br><div>Then perhaps we need more cases for copy=
 elision. Sneaky rvalue reference hacks will only provide surprises and mak=
e user code more brittle. If there must be an rvalue reference overload, it=
 should be named <font face=3D"Courier">move_value()</font> to indicate the=
 different semantic.</div><div><br></div></body></html>

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

--Apple-Mail=_5D3D7484-C4AA-4437-8142-084D173768DC--

.

On 10 July 2014 09:12, David Krauss <potswa@gmail.com> wrote:
>
> On 2014=E2=80=9307=E2=80=9310, at 2:04 PM, Ville Voutilainen <ville.vouti=
lainen@gmail.com>
> wrote:
>
> As a very general policy in C++ library design, every accessor to a stric=
tly
> owned resource should be lvalue-qualified and/or return by value. This be=
st
> practice should be applied across the standard library.
>
>
> I fail to see how that is "best practice=E2=80=9D.
>
>
> The resource is strictly owned and the owner is represented by an xvalue.
> Therefore the resource will be going away very soon. It would be incorrec=
t
> to return a reference to it.

There's two examples in this thread which explain why it's quite correct
in order to avoid extraneous temporaries and to allow forwarding to work
without metaprogramming tricks.

> Returning by rvalue reference may be tempting, but that is the semantic o=
f
> move(). It does not transfer ownership, it only provides the caller with =
a
> handle to accept ownership. Returning an rvalue reference is something on=
ly
> special functions should do.

I have no idea where this guideline popped out of.

> Then perhaps we need more cases for copy elision. Sneaky rvalue reference
> hacks will only provide surprises and make user code more brittle. If the=
re
> must be an rvalue reference overload, it should be named move_value() to
> indicate the different semantic.


That would be equally detrimental to users who want to forward.

--=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_31_922469.1404973122432
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



W dniu czwartek, 10 lipca 2014 08:12:55 UTC+2 u=C5=BCytkownik David Krauss=
=20
napisa=C5=82:
>
>
> On 2014=E2=80=9307=E2=80=9310, at 2:04 PM, Ville Voutilainen <ville.vo...=
@gmail.com=20
> <javascript:>> wrote:
>
> As a very general policy in C++ library design, every accessor to a=20
> strictly
> owned resource should be lvalue-qualified and/or return by value. This be=
st
> practice should be applied across the standard library.
>
>
> I fail to see how that is "best practice=E2=80=9D.
>
>
> The resource is strictly owned and the owner is represented by an xvalue.=
=20
> Therefore the resource will be going away very soon. It would be incorrec=
t=20
> to return a reference to it.
>
> Returning by rvalue reference may be tempting, but that is the semantic o=
f=20
> move(). It does not transfer ownership, it only provides the caller with =
a=20
> handle to accept ownership. Returning an rvalue reference is something on=
ly=20
> special functions should do.
>
> Whether returning a direct member or something owned elsewhere, methods o=
f
> an xvalue should always return by value. If a temporary might be introduc=
ed
> elsewhere, correctness is always worth the cost =E2=80=94 and copy elisio=
n will
> probably eliminate it anyway.
>
>
> Except that copy elision will not eliminate it, and this correctness
> is not worth
> the cost.
>
>
> Then perhaps we need more cases for copy elision. Sneaky rvalue reference=
=20
> hacks will only provide surprises and make user code more brittle. If the=
re=20
> must be an rvalue reference overload, it should be named move_value() to=
=20
> indicate the different semantic.
>
>
I dont see like introduing the rvalue reference overload that makes the=20
code works more coherent with current status qou, that is no reference=20
overlaod for getters provide more suprises that introducing temporaries in=
=20
places that they were not present before in existing codebases. Please also=
=20
remeber about forward.=20

--=20

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

------=_Part_31_922469.1404973122432
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>W dniu czwartek, 10 lipca 2014 08:12:55 UTC+2 u=C5=
=BCytkownik David Krauss napisa=C5=82:<blockquote class=3D"gmail_quote" sty=
le=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left=
: 1ex;"><div style=3D"word-wrap:break-word"><br><div><div>On 2014=E2=80=930=
7=E2=80=9310, at 2:04 PM, Ville Voutilainen &lt;<a href=3D"javascript:" tar=
get=3D"_blank" gdf-obfuscated-mailto=3D"rszrJvo-vZ0J" onmousedown=3D"this.h=
ref=3D'javascript:';return true;" onclick=3D"this.href=3D'javascript:';retu=
rn true;">ville.vo...@gmail.com</a>&gt; wrote:</div><br><blockquote type=3D=
"cite"><blockquote type=3D"cite">As a very general policy in C++ library de=
sign, every accessor to a strictly<br>owned resource should be lvalue-quali=
fied and/or return by value. This best<br>practice should be applied across=
 the standard library.<br></blockquote><br>I fail to see how that is "best =
practice=E2=80=9D.<br></blockquote><div><br></div><div>The resource is stri=
ctly owned and the owner is represented by an xvalue. Therefore the resourc=
e will be going away very soon. It would be incorrect to return a reference=
 to it.</div><div><br></div><div>Returning by rvalue reference may be tempt=
ing, but that is the semantic of move(). It does not transfer ownership, it=
 only provides the caller with a handle to accept ownership. Returning an r=
value reference is something only special functions should do.</div><br><bl=
ockquote type=3D"cite"><blockquote type=3D"cite">Whether returning a direct=
 member or something owned elsewhere, methods of<br>an xvalue should always=
 return by value. If a temporary might be introduced<br>elsewhere, correctn=
ess is always worth the cost =E2=80=94 and copy elision will<br>probably el=
iminate it anyway.<br></blockquote><br>Except that copy elision will not el=
iminate it, and this correctness<br>is not worth<br>the cost.<br></blockquo=
te></div><br><div>Then perhaps we need more cases for copy elision. Sneaky =
rvalue reference hacks will only provide surprises and make user code more =
brittle. If there must be an rvalue reference overload, it should be named =
<font face=3D"Courier">move_value()</font> to indicate the different semant=
ic.</div><div><br></div></div></blockquote><div><br>I dont see like introdu=
ing the rvalue reference overload that makes the code works more coherent w=
ith current status qou, that is no reference overlaod for getters provide m=
ore suprises that introducing temporaries in places that they were not pres=
ent before in existing codebases. Please also remeber about forward. <br></=
div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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_31_922469.1404973122432--

.

--Apple-Mail=_2FA755DB-8D95-40E3-86AF-7CADEF8F0222
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8


On 2014=E2=80=9307=E2=80=9310, at 2:10 PM, tomaszkam@gmail.com wrote:

>=20
> W dniu czwartek, 10 lipca 2014 07:48:29 UTC+2 u=C5=BCytkownik David Kraus=
s napisa=C5=82:
>=20
> On 2014=E2=80=9307=E2=80=9310, at 1:11 PM, toma...@gmail.com wrote:
>=20
>> W dniu czwartek, 10 lipca 2014 01:17:39 UTC+2 u=C5=BCytkownik David Krau=
ss napisa=C5=82:
>>=20
>> auto && has some strong proponents, and although nothing is a silver bul=
let, it will always work except when a function returns an rvalue reference=
 =E2=80=94 which, as the title of this thread and most of the early message=
s indicate, is a problem to be fixed.
>=20
>> No, the auto&& does not work with any function that return a any kind of=
 reference to subobject of it parameter (including this) is invoked on an r=
value. In the examples above you my find:
>> std::vector<std::string> f();
>> auto&& s =3D f.front();
>> //This creates a dangling lvalue reference, and front() has not r-value =
overloads.
>=20
> I think you mean f().front(). As per this thread, or maybe it=E2=80=99s j=
ust my extrapolation, the solution is to add an rvalue-ref qualified overlo=
ad returning by value.
>=20
> As a very general policy in C++ library design, every accessor to a stric=
tly owned resource should be lvalue-qualified and/or return by value. This =
best practice should be applied across the standard library.
>=20
> And dou you expect the following to also work (example presented above): =
 =20
>       auto&& s =3D *f.begin();

Assuming you mean * ( f().begin() ), I would expect that to be currently br=
oken, but the fix is to forbid begin() and end() on an xvalue because they =
are fundamentally nonsense. It=E2=80=99s a minor issue that some would-be i=
ll-formed code is currently accepted.

> In addition: "Of course binding a reference to a subobject extends the co=
mplete object. What else do you want, destruction of the rest of the object=
 *except* the subobject??"
> Llets assume following scenario:
> struct Result
> {
>     std::string array[100];
>     std::string& best; //best points to one element of array, making it b=
y reference stop at least assigment
> };=20
>=20
> //Lets assume that the following class returns array of 100 elements and =
hint for the best element
> Result foo();
>=20
> //Then you would like the following to work
> auto&& cs =3D foo().best;

No, lifetime extension doesn=E2=80=99t work like that. It=E2=80=99s never b=
een transitive. However even in C++98 this worked:

std::string const & cs =3D foo().best; // Lifetime extension since C++98

See 14882:1998 =C2=A712.2/5:

> The temporary to which the reference is bound or the temporary that is th=
e complete object to a subobject of which the temporary is bound persists f=
or the lifetime of the reference except as specified below.

It does not mention base subobjects specifically.

> Please stop this make "auto&&" movment, becuase it is now going insea wit=
h breaking existing code, to make this single statment work. The problem li=
es in usign the extension of temporaries by binding in block scope.

No existing code is getting broken. The semantics of rvalue references are =
understood pretty well now and it=E2=80=99s a completely consistent system.

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

--Apple-Mail=_2FA755DB-8D95-40E3-86AF-7CADEF8F0222
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;"><br><div><div>On 2014=E2=80=
=9307=E2=80=9310, at 2:10 PM, <a href=3D"mailto:tomaszkam@gmail.com">tomasz=
kam@gmail.com</a> wrote:</div><br class=3D"Apple-interchange-newline"><bloc=
kquote type=3D"cite"><div dir=3D"ltr"><br>W dniu czwartek, 10 lipca 2014 07=
:48:29 UTC+2 u=C5=BCytkownik David Krauss napisa=C5=82:<blockquote class=3D=
"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc s=
olid;padding-left: 1ex;"><div style=3D"word-wrap:break-word"><br><div><div>=
On 2014=E2=80=9307=E2=80=9310, at 1:11 PM, <a href=3D"javascript:" target=
=3D"_blank" gdf-obfuscated-mailto=3D"2_2y_Hm6SEcJ" onmousedown=3D"this.href=
=3D'javascript:';return true;" onclick=3D"this.href=3D'javascript:';return =
true;">toma...@gmail.com</a> wrote:</div><br><blockquote type=3D"cite"><div=
 dir=3D"ltr">W dniu czwartek, 10 lipca 2014 01:17:39 UTC+2 u=C5=BCytkownik =
David Krauss napisa=C5=82:<blockquote class=3D"gmail_quote" style=3D"margin=
:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204)=
;border-left-style:solid;padding-left:1ex"><div style=3D"word-wrap:break-wo=
rd"><br><div><font face=3D"Courier">auto &amp;&amp;</font> has some strong =
proponents, and although nothing is a silver bullet, it will always work ex=
cept when a function returns an rvalue reference =E2=80=94 which, as the ti=
tle of this thread and most of the early messages indicate, is a problem to=
 be fixed.</div></div></blockquote></div></blockquote><br><blockquote type=
=3D"cite"><div dir=3D"ltr">No, the auto&amp;&amp; does not work with any fu=
nction that return a any kind of reference to subobject of it parameter (in=
cluding this) is invoked on an rvalue. In the examples above you my find:<b=
r>std::vector&lt;std::string&gt; f();<br>auto&amp;&amp; s =3D f.front();<br=
>//This creates a dangling lvalue reference, and front() has not r-value ov=
erloads.<br></div></blockquote><div><br></div><div>I think you mean <font f=
ace=3D"Courier">f().front()</font>. As per this thread, or maybe it=E2=80=
=99s just my extrapolation, the solution is to add an rvalue-ref qualified =
overload returning by value.</div><div><br></div><div>As a very general pol=
icy in C++ library design, every accessor to a strictly owned resource shou=
ld be lvalue-qualified and/or return by value. This best practice should be=
 applied across the standard library.</div><div><br></div></div></div></blo=
ckquote><div>And dou you expect the following to also work (example present=
ed above):&nbsp;&nbsp; <br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; auto&amp;&amp; s =
=3D *f.begin();<br></div></div></blockquote><div><br></div><div>Assuming yo=
u mean <font face=3D"Courier">* ( f().begin() )</font>, I would expect that=
 to be currently broken, but the fix is to forbid <font face=3D"Courier">be=
gin()</font> and <font face=3D"Courier">end()</font> on an xvalue because t=
hey are fundamentally nonsense. It=E2=80=99s a minor issue that some would-=
be ill-formed code is currently accepted.</div><br><blockquote type=3D"cite=
"><div dir=3D"ltr"><div>In addition: "Of course binding a reference to a su=
bobject extends
 the complete object. What else do you want, destruction of the rest of=20
the object *<i>except</i>* the subobject??"<br>Llets assume following scena=
rio:<br>struct Result<br>{<br>&nbsp;&nbsp;&nbsp; std::string array[100];<br=
>&nbsp;&nbsp;&nbsp; std::string&amp; best; //best points to one element of =
array, making it by reference stop at least assigment<br>}; <br><br>//Lets =
assume that the following class returns array of 100 elements and hint for =
the best element<br>Result foo();<br><br>//Then you would like the followin=
g to work<br>auto&amp;&amp; cs =3D foo().best;<br></div></div></blockquote>=
<div><br></div><div>No, lifetime extension doesn=E2=80=99t work like that. =
It=E2=80=99s never been transitive. However even in C++98 this worked:</div=
><div><br></div><div><font face=3D"Courier">std::string const &amp; cs =3D =
foo().best; // Lifetime extension since C++98</font></div><div><br></div><d=
iv>See 14882:1998 =C2=A712.2/5:</div><div><br></div><div></div><blockquote =
type=3D"cite"><div>The temporary to which the reference is&nbsp;bound or th=
e temporary that is the complete object to a subobject of which the&nbsp;te=
mporary is bound persists&nbsp;for the lifetime of the reference except as =
specified below.</div></blockquote><div><br></div>It does not mention base =
subobjects specifically.<br><br><blockquote type=3D"cite"><div dir=3D"ltr">=
<div>Please stop this make "auto&amp;&amp;" movment, becuase it is now goin=
g insea with breaking existing code, to make this single statment work. The=
 problem lies in usign the extension of temporaries by binding in block sco=
pe.</div></div></blockquote><div><br></div></div>No existing code is gettin=
g broken. The semantics of rvalue references are understood pretty well now=
 and it=E2=80=99s a completely consistent system.<br><div><br></div></body>=
</html>

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

--Apple-Mail=_2FA755DB-8D95-40E3-86AF-7CADEF8F0222--

.

--Apple-Mail=_624E72F2-A725-4634-BC33-269A15A4996B
Content-Type: text/plain; charset=ISO-8859-1


On 2014-07-10, at 2:17 PM, Ville Voutilainen <ville.voutilainen@gmail.com> wrote:

>> Returning by rvalue reference may be tempting, but that is the semantic of
>> move(). It does not transfer ownership, it only provides the caller with a
>> handle to accept ownership. Returning an rvalue reference is something only
>> special functions should do.
>
> I have no idea where this guideline popped out of.

Which part? Name three functions that return an rvalue reference. There's move(), forward(), and ??? .

>> Then perhaps we need more cases for copy elision. Sneaky rvalue reference
>> hacks will only provide surprises and make user code more brittle. If there
>> must be an rvalue reference overload, it should be named move_value() to
>> indicate the different semantic.
>
>
> That would be equally detrimental to users who want to forward.

So, call it forward_value() with appropriate semantics. It's equally a bad idea to bind a named reference to move() or forward().

--

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

--Apple-Mail=_624E72F2-A725-4634-BC33-269A15A4996B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014&=
ndash;07&ndash;10, at 2:17 PM, Ville Voutilainen &lt;<a href=3D"mailto:vill=
e.voutilainen@gmail.com">ville.voutilainen@gmail.com</a>&gt; wrote:</div><b=
r><blockquote type=3D"cite"><div style=3D"font-size: 12px; font-style: norm=
al; font-variant: normal; font-weight: normal; letter-spacing: normal; line=
-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-t=
ransform: none; white-space: normal; widows: auto; word-spacing: 0px; -webk=
it-text-stroke-width: 0px;"><blockquote type=3D"cite">Returning by rvalue r=
eference may be tempting, but that is the semantic of<br>move(). It does no=
t transfer ownership, it only provides the caller with a<br>handle to accep=
t ownership. Returning an rvalue reference is something only<br>special fun=
ctions should do.<br></blockquote><br>I have no idea where this guideline p=
opped out of.<br></div></blockquote><div><br></div><div>Which part? Name th=
ree functions that return an rvalue reference. There&rsquo;s move(), forwar=
d(), and ??? .</div><br><blockquote type=3D"cite"><div style=3D"font-size: =
12px; font-style: normal; font-variant: normal; font-weight: normal; letter=
-spacing: normal; line-height: normal; orphans: auto; text-align: start; te=
xt-indent: 0px; text-transform: none; white-space: normal; widows: auto; wo=
rd-spacing: 0px; -webkit-text-stroke-width: 0px;"><blockquote type=3D"cite"=
>Then perhaps we need more cases for copy elision. Sneaky rvalue reference<=
br>hacks will only provide surprises and make user code more brittle. If th=
ere<br>must be an rvalue reference overload, it should be named move_value(=
) to<br>indicate the different semantic.<br></blockquote><br><br>That would=
 be equally detrimental to users who want to forward.<br></div></blockquote=
><div><br></div><div>So, call it <font face=3D"Courier">forward_value()</fo=
nt> with appropriate semantics. It&rsquo;s equally a bad idea to bind a nam=
ed reference to <font face=3D"Courier">move()</font> or <font face=3D"Couri=
er">forward()</font>.</div></div><br></body></html>

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

--Apple-Mail=_624E72F2-A725-4634-BC33-269A15A4996B--

.

On 10 July 2014 09:20, David Krauss <potswa@gmail.com> wrote:
>
> On 2014=E2=80=9307=E2=80=9310, at 2:10 PM, tomaszkam@gmail.com wrote:
> And dou you expect the following to also work (example presented above):
>       auto&& s =3D *f.begin();
>
>
> Assuming you mean * ( f().begin() ), I would expect that to be currently
> broken, but the fix is to forbid begin() and end() on an xvalue because t=
hey
> are fundamentally nonsense. It=E2=80=99s a minor issue that some would-be=
 ill-formed
> code is currently accepted.


These "fundamentally nonsense" operations work perfectly fine in forwarding
scenarios.

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

.

--Apple-Mail=_6B566DBD-7042-4F37-990B-D146F9A85EB2
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1


On 2014-07-10, at 2:18 PM, tomaszkam@gmail.com wrote:

> I dont see like introduing the rvalue reference overload that makes the c=
ode works more coherent with current status qou, that is no reference overl=
aod for getters provide more suprises that introducing temporaries in place=
s that they were not present before in existing codebases. Please also reme=
ber about forward.=20

You want to introduce a function named value() that returns something other=
 than a value. Is that coherent?

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

--Apple-Mail=_6B566DBD-7042-4F37-990B-D146F9A85EB2
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014&=
ndash;07&ndash;10, at 2:18 PM, <a href=3D"mailto:tomaszkam@gmail.com">tomas=
zkam@gmail.com</a> wrote:</div><br class=3D"Apple-interchange-newline"><blo=
ckquote type=3D"cite"><div style=3D"font-family: Helvetica; font-size: 12px=
; font-style: normal; font-variant: normal; font-weight: normal; letter-spa=
cing: normal; line-height: normal; orphans: auto; text-align: start; text-i=
ndent: 0px; text-transform: none; white-space: normal; widows: auto; word-s=
pacing: 0px; -webkit-text-stroke-width: 0px;"><div dir=3D"ltr">I dont see l=
ike introduing the rvalue reference overload that makes the code works more=
 coherent with current status qou, that is no reference overlaod for getter=
s provide more suprises that introducing temporaries in places that they we=
re not present before in existing codebases. Please also remeber about forw=
ard.&nbsp;</div></div></blockquote><div><br></div><div>You want to introduc=
e a function named value() that returns something other than a value. Is th=
at coherent?</div></div><br></body></html>

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

--Apple-Mail=_6B566DBD-7042-4F37-990B-D146F9A85EB2--

.

On 2014-07-10, at 2:23 PM, Ville Voutilainen <ville.voutilainen@gmail.com> wrote:

> On 10 July 2014 09:20, David Krauss <potswa@gmail.com> wrote:
>>
>> On 2014-07-10, at 2:10 PM, tomaszkam@gmail.com wrote:
>> And dou you expect the following to also work (example presented above):
>>      auto&& s = *f.begin();
>>
>>
>> Assuming you mean * ( f().begin() ), I would expect that to be currently
>> broken, but the fix is to forbid begin() and end() on an xvalue because they
>> are fundamentally nonsense. It's a minor issue that some would-be ill-formed
>> code is currently accepted.
>
>
> These "fundamentally nonsense" operations work perfectly fine in forwarding
> scenarios.

It's easy enough to bind an xvalue to a name throughout the scope it does not behave as an xvalue.

Maybe I don't see exactly what you mean by "forwarding scenario," an example would be nice.

--

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

.

On 10 July 2014 09:22, David Krauss <potswa@gmail.com> wrote:
>
> On 2014=E2=80=9307=E2=80=9310, at 2:17 PM, Ville Voutilainen <ville.vouti=
lainen@gmail.com>
> wrote:
>
> Returning by rvalue reference may be tempting, but that is the semantic o=
f
> move(). It does not transfer ownership, it only provides the caller with =
a
> handle to accept ownership. Returning an rvalue reference is something on=
ly
> special functions should do.
>
>
> I have no idea where this guideline popped out of.
>
>
> Which part? Name three functions that return an rvalue reference. There=
=E2=80=99s
> move(), forward(), and ??? .

get() from a pair rvalue, get() from a tuple rvalue, get() from an array rv=
alue.

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

.

On 10 July 2014 09:26, David Krauss <potswa@gmail.com> wrote:
>>> Assuming you mean * ( f().begin() ), I would expect that to be currently
>>> broken, but the fix is to forbid begin() and end() on an xvalue because they
>>> are fundamentally nonsense. It's a minor issue that some would-be ill-formed
>>> code is currently accepted.
>>
>>
>> These "fundamentally nonsense" operations work perfectly fine in forwarding
>> scenarios.
>
> It's easy enough to bind an xvalue to a name throughout the scope it does not behave as an xvalue.

I fail to see what sort of a solution that is supposed to provide.

> Maybe I don't see exactly what you mean by "forwarding scenario," an example would be nice.

The example is in this thread, as has been said multiple times already.
https://groups.google.com/a/isocpp.org/d/msg/std-proposals/jDRQyBWYl8Q/iLJFlolCOBgJ

We currently have ample reasons to change the rvalue-ref-qualified
overloads of optional
observers to return T&& instead of T. The summary, for those who don't
read threads before
jumping into them head first, is in
https://issues.isocpp.org/show_bug.cgi?id=45

--

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

.

--Apple-Mail=_031FECB8-89A6-4AF4-96C3-ED0075F4423F
Content-Type: text/plain; charset=ISO-8859-1


On 2014-07-10, at 2:27 PM, Ville Voutilainen <ville.voutilainen@gmail.com> wrote:

> On 10 July 2014 09:22, David Krauss <potswa@gmail.com> wrote:
>>
>> Which part? Name three functions that return an rvalue reference. There's
>> move(), forward(), and ??? .
>
> get() from a pair rvalue, get() from a tuple rvalue, get() from an array rvalue.

Sounds like a defect. Any more I should know about? This is interesting.

It's interesting that the standard library provides these quiet moves, without a corresponding value() function to accept an rvalue reference and assume ownership.

--

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

--Apple-Mail=_031FECB8-89A6-4AF4-96C3-ED0075F4423F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014&=
ndash;07&ndash;10, at 2:27 PM, Ville Voutilainen &lt;<a href=3D"mailto:vill=
e.voutilainen@gmail.com">ville.voutilainen@gmail.com</a>&gt; wrote:</div><b=
r class=3D"Apple-interchange-newline"><blockquote type=3D"cite"><div style=
=3D"font-size: 12px; font-style: normal; font-variant: normal; font-weight:=
 normal; letter-spacing: normal; line-height: normal; orphans: auto; text-a=
lign: start; text-indent: 0px; text-transform: none; white-space: normal; w=
idows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">On 10 July=
 2014 09:22, David Krauss &lt;<a href=3D"mailto:potswa@gmail.com">potswa@gm=
ail.com</a>&gt; wrote:<br><blockquote type=3D"cite"><br>Which part? Name th=
ree functions that return an rvalue reference. There&rsquo;s<br>move(), for=
ward(), and ??? .<br></blockquote><br>get() from a pair rvalue, get() from =
a tuple rvalue, get() from an array rvalue.<br></div></blockquote></div><br=
><div>Sounds like a defect. Any more I should know about? This is interesti=
ng.</div><div><br></div><div>It&rsquo;s interesting that the standard libra=
ry provides these quiet moves, without a corresponding value() function to =
accept an rvalue reference and assume ownership.</div><div><br></div></body=
></html>

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

--Apple-Mail=_031FECB8-89A6-4AF4-96C3-ED0075F4423F--

.

On 10 July 2014 09:33, David Krauss <potswa@gmail.com> wrote:
>
> On 2014=E2=80=9307=E2=80=9310, at 2:27 PM, Ville Voutilainen <ville.vouti=
lainen@gmail.com>
> wrote:
>
> On 10 July 2014 09:22, David Krauss <potswa@gmail.com> wrote:
>
>
> Which part? Name three functions that return an rvalue reference. There=
=E2=80=99s
> move(), forward(), and ??? .
>
>
> get() from a pair rvalue, get() from a tuple rvalue, get() from an array
> rvalue.
>
>
> Sounds like a defect. Any more I should know about? This is interesting.

Well, pretty soon optional::operator*, optional::value as well.

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

.

--Apple-Mail=_33621C48-702D-40EB-B036-8C11B56B21F4
Content-Type: text/plain; charset=ISO-8859-1


On 2014-07-10, at 2:31 PM, Ville Voutilainen <ville.voutilainen@gmail.com> wrote:

> On 10 July 2014 09:26, David Krauss <potswa@gmail.com> wrote:
>>>> Assuming you mean * ( f().begin() ), I would expect that to be currently
>>>> broken, but the fix is to forbid begin() and end() on an xvalue because they
>>>> are fundamentally nonsense. It's a minor issue that some would-be ill-formed
>>>> code is currently accepted.
>>>
>>>
>>> These "fundamentally nonsense" operations work perfectly fine in forwarding
>>> scenarios.
>>
>> It's easy enough to bind an xvalue to a name throughout the scope it does not behave as an xvalue.
>
> I fail to see what sort of a solution that is supposed to provide.

An xvalue by definition a kind of expression whose value is going away soon. Nobody should use an xvalue in any other context. An xvalue is presumed to be empty (but maybe not) at the semicolon.

If you're going to iterate over a sequence within a container, but you got the first iterator from an xvalue, then the sequence is presumed to be dead by the first statement in the loop.

In the context of not iterating, then it would make sense to allow a move_iterator, but that's a little far-fetched. Rvalue qualified front() and back() should be good enough for idiomatic use.

>> Maybe I don't see exactly what you mean by "forwarding scenario," an example would be nice.
>
> The example is in this thread, as has been said multiple times already.
> https://groups.google.com/a/isocpp.org/d/msg/std-proposals/jDRQyBWYl8Q/iLJFlolCOBgJ

That's just a link to this thread, to a message containing another link. The text begin() does not occur in that thread.

> We currently have ample reasons to change the rvalue-ref-qualified
> overloads of optional
> observers to return T&& instead of T. The summary, for those who don't
> read threads before
> jumping into them head first, is in
> https://issues.isocpp.org/show_bug.cgi?id=45

I cannot access the isocpp.org server.

--

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

--Apple-Mail=_33621C48-702D-40EB-B036-8C11B56B21F4
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014&=
ndash;07&ndash;10, at 2:31 PM, Ville Voutilainen &lt;<a href=3D"mailto:vill=
e.voutilainen@gmail.com">ville.voutilainen@gmail.com</a>&gt; wrote:</div><b=
r class=3D"Apple-interchange-newline"><blockquote type=3D"cite">On 10 July =
2014 09:26, David Krauss &lt;<a href=3D"mailto:potswa@gmail.com">potswa@gma=
il.com</a>&gt; wrote:<br><blockquote type=3D"cite"><blockquote type=3D"cite=
"><blockquote type=3D"cite">Assuming you mean * ( f().begin() ), I would ex=
pect that to be currently<br>broken, but the fix is to forbid begin() and e=
nd() on an xvalue because they<br>are fundamentally nonsense. It's a minor =
issue that some would-be ill-formed<br>code is currently accepted.<br></blo=
ckquote><br><br>These "fundamentally nonsense" operations work perfectly fi=
ne in forwarding<br>scenarios.<br></blockquote><br>It's easy enough to bind=
 an xvalue to a name throughout the scope it does not behave as an xvalue.<=
br></blockquote><br>I fail to see what sort of a solution that is supposed =
to provide.<br></blockquote><div><br></div><div>An xvalue by definition a k=
ind of expression whose value is going away soon. Nobody should use an xval=
ue in any other context. An xvalue is presumed to be empty (but maybe not) =
at the semicolon.</div><div><br></div><div>If you&rsquo;re going to iterate=
 over a sequence within a container, but you got the first iterator from an=
 xvalue, then the sequence is presumed to be dead by the first statement in=
 the loop.</div><div><br></div><div>In the context of not iterating, then i=
t would make sense to allow a <font face=3D"Courier">move_iterator</font>, =
but that&rsquo;s a little far-fetched. Rvalue qualified <font face=3D"Couri=
er">front()</font> and <font face=3D"Courier">back()</font> should be good =
enough for idiomatic use.</div><br><blockquote type=3D"cite"><blockquote ty=
pe=3D"cite">Maybe I don't see exactly what you mean by "forwarding scenario=
," an example would be nice.<br></blockquote><br>The example is in this thr=
ead, as has been said multiple times already.<br><a href=3D"https://groups.=
google.com/a/isocpp.org/d/msg/std-proposals/jDRQyBWYl8Q/iLJFlolCOBgJ">https=
://groups.google.com/a/isocpp.org/d/msg/std-proposals/jDRQyBWYl8Q/iLJFlolCO=
BgJ</a><br></blockquote><div><br></div><div>That&rsquo;s just a link to thi=
s thread, to a message containing another link. The text <font face=3D"Cour=
ier">begin()</font> does not occur in that thread.</div><br><blockquote typ=
e=3D"cite">We currently have ample reasons to change the rvalue-ref-qualifi=
ed<br>overloads of optional<br>observers to return T&amp;&amp; instead of T=
.. The summary, for those who don't<br>read threads before<br>jumping into t=
hem head first, is in<br><a href=3D"https://issues.isocpp.org/show_bug.cgi?=
id=3D45">https://issues.isocpp.org/show_bug.cgi?id=3D45</a><br></blockquote=
><div><br></div>I cannot access the <a href=3D"http://isocpp.org">isocpp.or=
g</a> server.</div><div><br></div></body></html>

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

--Apple-Mail=_33621C48-702D-40EB-B036-8C11B56B21F4--

.

On 10 July 2014 09:41, David Krauss <potswa@gmail.com> wrote:
> If you=E2=80=99re going to iterate over a sequence within a container, bu=
t you got
> the first iterator from an xvalue, then the sequence is presumed to be de=
ad
> by the first statement in the loop.

The sequence is not dead if I pass the iterator onto a processing function
before the xvalue expires. Which is precisely what the general forwarding c=
ases
do, and what emplace does.

> The example is in this thread, as has been said multiple times already.
> https://groups.google.com/a/isocpp.org/d/msg/std-proposals/jDRQyBWYl8Q/iL=
JFlolCOBgJ
>
>
> That=E2=80=99s just a link to this thread, to a message containing anothe=
r link. The
> text begin() does not occur in that thread.

Yeah, well, that message shows the "forwarding scenario".

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

.

--Apple-Mail=_21E15F34-7244-4CA2-97E4-8D9FDF9F6CD9
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1


On 2014-07-10, at 2:49 PM, Ville Voutilainen <ville.voutilainen@gmail.com> =
wrote:

> On 10 July 2014 09:41, David Krauss <potswa@gmail.com> wrote:
>> If you're going to iterate over a sequence within a container, but you g=
ot
>> the first iterator from an xvalue, then the sequence is presumed to be d=
ead
>> by the first statement in the loop.
>=20
> The sequence is not dead if I pass the iterator onto a processing functio=
n
> before the xvalue expires. Which is precisely what the general forwarding=
 cases
> do, and what emplace does.

Passing an iterator with the guarantee that the function will not retain a =
reference into the sequence is fine, but that doesn't lend meaning to std::=
forward< Container >( container ).begin(). If the container is still expect=
ed to be valid at the semicolon, then do not move/forward. If the sequence =
algorithm is supposed to move-from the sequence, then use a std::move_itera=
tor instead. Perhaps there's a use-case for a std::forward_iterator (perhap=
s just as an alias template) but I don't see that following directly from w=
hat you've suggested so far.

I'd still like to see an example of what begin() on an xvalue is supposed t=
o accomplish.

>> The example is in this thread, as has been said multiple times already.
>> https://groups.google.com/a/isocpp.org/d/msg/std-proposals/jDRQyBWYl8Q/i=
LJFlolCOBgJ
>>=20
>>=20
>> That's just a link to this thread, to a message containing another link.=
 The
>> text begin() does not occur in that thread.
>=20
> Yeah, well, that message shows the "forwarding scenario".

OK, I'll try to parse it. It doesn't relate to a sequence. The function nam=
e means nothing. The point is simply that returning a reference avoids movi=
ng through a temporary in this case, so what? This isn't the kind of justif=
ication and writeup that I'd expect for something as broad as a library-wid=
e policy about the interaction of value category with function returns. (Th=
e author clearly didn't have such grand intent, to be fair.)

Risky micro-optimization should never be the default. If forward-by-referen=
ce returns are sometimes desired for performance, then add them under a fun=
ction name like forward_*() or provide a suitable additional sibling to std=
::forward() to handle such cases. Do not foist the hack on everyone.

Function returns should have predictable value category, whatever your pref=
erence for safety vs. speed. If the function specification must depend on p=
erformance, then the correct standard library specification would be to lea=
ve it implementation-defined. However, it's a false dichotomy because you c=
an always introduce a new name for new behavior.

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

--Apple-Mail=_21E15F34-7244-4CA2-97E4-8D9FDF9F6CD9
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014&=
ndash;07&ndash;10, at 2:49 PM, Ville Voutilainen &lt;<a href=3D"mailto:vill=
e.voutilainen@gmail.com">ville.voutilainen@gmail.com</a>&gt; wrote:</div><b=
r class=3D"Apple-interchange-newline"><blockquote type=3D"cite">On 10 July =
2014 09:41, David Krauss &lt;<a href=3D"mailto:potswa@gmail.com">potswa@gma=
il.com</a>&gt; wrote:<br><blockquote type=3D"cite">If you&rsquo;re going to=
 iterate over a sequence within a container, but you got<br>the first itera=
tor from an xvalue, then the sequence is presumed to be dead<br>by the firs=
t statement in the loop.<br></blockquote><br>The sequence is not dead if I =
pass the iterator onto a processing function<br>before the xvalue expires. =
Which is precisely what the general forwarding cases<br>do, and what emplac=
e does.<br></blockquote><div><br></div><div>Passing an iterator with the gu=
arantee that the function will not retain a reference into the sequence is =
fine, but that doesn&rsquo;t lend meaning to <font face=3D"Courier">std::fo=
rward&lt; Container &gt;( container ).begin()</font>. If the container is s=
till expected to be valid at the semicolon, then do not move/forward. If th=
e sequence algorithm is supposed to move-from the sequence, then use a <fon=
t face=3D"Courier">std::move_iterator</font> instead. Perhaps there&rsquo;s=
 a use-case for a <font face=3D"Courier">std::forward_iterator</font>&nbsp;=
(perhaps just as an alias template) but I don&rsquo;t see that following di=
rectly from what you&rsquo;ve suggested so far.</div><div><br></div><div>I&=
rsquo;d still like to see an example of what <font face=3D"Courier">begin()=
</font> on an xvalue is supposed to accomplish.</div><br><blockquote type=
=3D"cite"><blockquote type=3D"cite">The example is in this thread, as has b=
een said multiple times already.<br><a href=3D"https://groups.google.com/a/=
isocpp.org/d/msg/std-proposals/jDRQyBWYl8Q/iLJFlolCOBgJ">https://groups.goo=
gle.com/a/isocpp.org/d/msg/std-proposals/jDRQyBWYl8Q/iLJFlolCOBgJ</a><br><b=
r><br>That&rsquo;s just a link to this thread, to a message containing anot=
her link. The<br>text begin() does not occur in that thread.<br></blockquot=
e><br>Yeah, well, that message shows the "forwarding scenario&rdquo;.<br></=
blockquote><div><br></div><div>OK, I&rsquo;ll try to parse it. It doesn&rsq=
uo;t relate to a sequence. The function name means nothing. The point is si=
mply that returning a reference avoids moving through a temporary in this c=
ase, so what? This isn&rsquo;t the kind of justification and writeup that I=
&rsquo;d expect for something as broad as a library-wide policy about the i=
nteraction of value category with function returns. (The author clearly did=
n&rsquo;t have such grand intent, to be fair.)</div><div><br></div><div>Ris=
ky micro-optimization should never be the default. If forward-by-reference =
returns are sometimes desired for performance, then add them under a functi=
on name like <font face=3D"Courier">forward_*()</font>&nbsp;or provide a su=
itable additional sibling to&nbsp;<font face=3D"Courier">std::forward()</fo=
nt> to handle such cases. Do not foist the hack on everyone.</div><div><br>=
</div><div>Function returns should have predictable value category, whateve=
r your preference for safety vs. speed. If the function specification must =
depend on performance, then the correct standard library specification woul=
d be to leave it implementation-defined. However, it&rsquo;s a false dichot=
omy because you can always introduce a new name for new behavior.</div><div=
><br></div></div></body></html>

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

--Apple-Mail=_21E15F34-7244-4CA2-97E4-8D9FDF9F6CD9--

.

On 10 July 2014 11:58, David Krauss <potswa@gmail.com> wrote:
> Risky micro-optimization should never be the default. If

It's not a micro-optimization.

> forward-by-reference returns are sometimes desired for performance, then add
> them under a function name like forward_*() or provide a suitable additional
> sibling to std::forward() to handle such cases. Do not foist the hack on
> everyone.


The standard library already "foists the hack" on everyone. For,
apparently, good
reasons.

--

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

.

--Apple-Mail=_6A25EAEC-9D24-4957-B612-65B9F7117840
Content-Type: text/plain; charset=ISO-8859-1


On 2014-07-10, at 5:01 PM, Ville Voutilainen <ville.voutilainen@gmail.com> wrote:

> On 10 July 2014 11:58, David Krauss <potswa@gmail.com> wrote:
>> Risky micro-optimization should never be the default. If
>
> It's not a micro-optimization.

Eliminating one move is a micro-optimization.

>> forward-by-reference returns are sometimes desired for performance, then add
>> them under a function name like forward_*() or provide a suitable additional
>> sibling to std::forward() to handle such cases. Do not foist the hack on
>> everyone.
>
> The standard library already "foists the hack" on everyone. For,
> apparently, good
> reasons.

In exactly one function? std::get does not count separately for each overload, sorry. This does not set much of a precedent.

--

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

--Apple-Mail=_6A25EAEC-9D24-4957-B612-65B9F7117840
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014&=
ndash;07&ndash;10, at 5:01 PM, Ville Voutilainen &lt;<a href=3D"mailto:vill=
e.voutilainen@gmail.com">ville.voutilainen@gmail.com</a>&gt; wrote:</div><b=
r class=3D"Apple-interchange-newline"><blockquote type=3D"cite">On 10 July =
2014 11:58, David Krauss &lt;<a href=3D"mailto:potswa@gmail.com">potswa@gma=
il.com</a>&gt; wrote:<br><blockquote type=3D"cite">Risky micro-optimization=
 should never be the default. If<br></blockquote><br>It's not a micro-optim=
ization.<br></blockquote><div><br></div><div>Eliminating one move is a micr=
o-optimization.</div><br><blockquote type=3D"cite"><blockquote type=3D"cite=
">forward-by-reference returns are sometimes desired for performance, then =
add<br>them under a function name like forward_*() or provide a suitable ad=
ditional<br>sibling to std::forward() to handle such cases. Do not foist th=
e hack on<br>everyone.<br></blockquote><br>The standard library already "fo=
ists the hack" on everyone. For,<br>apparently, good<br>reasons.<br></block=
quote><div><br></div>In exactly one function? <font face=3D"Courier">std::g=
et</font> does not count separately for each overload, sorry. This does not=
 set much of a precedent.<br></div><div><br></div></body></html>

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

--Apple-Mail=_6A25EAEC-9D24-4957-B612-65B9F7117840--

.

------=_Part_82_21799650.1404984557394
Content-Type: text/plain; charset=UTF-8

To be clear, the value function definied in the following text has
following definition before the change:
  T& value();
  T const& value() const;
This function depsite the name does not return anything by value and haser
the same relaction with operator*, like operator[] with at in vector.

In the paper that I mentonied in original post following overloads was
added:
  T& value() &;
  T const& value() const &;
  T value() &&;
  T value() const &&;
Which makes following invoaction f(expr.value()) where takes T by const&
and expr is value of type optional<T>, introducing has additonal
possibly-copy dependin on expr being lvalue or r-value. And makes using
optional in generic context when perfect forwardin us used a pain. I
propose to set of methods to look like:
  T& value() &;
  T const& value() const &;
  T&& value() &&;
 To achieve consistency with std::get function or even simple meber acces
with procudes same cateogry value for subobject.

If the original set  of the methods was:
  T  value() const;
I would arrge tthe the new function should be declared as:
  T  value() const;
  T  value() &&;
But this is not

--

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

<div dir=3D"ltr">To be clear, the value function definied in the following =
text has following definition before the change:<br>&nbsp; T&amp; value();<=
br>&nbsp; T const&amp; value() const;<br>This function depsite the name doe=
s not return anything by value and haser the same relaction with operator*,=
 like operator[] with at in vector.<br><br>In the paper that I mentonied in=
 original post following overloads was added:<br>&nbsp;  T&amp; value() &am=
p;;<br>&nbsp; T const&amp; value() const &amp;;<br>&nbsp; T value() &amp;&a=
mp;;<br>&nbsp; T value() const &amp;&amp;;<br>Which makes following invoact=
ion f(expr.value()) where takes T by const&amp; and expr is value of type o=
ptional&lt;T&gt;, introducing has additonal possibly-copy dependin on expr =
being lvalue or r-value. And makes using optional in generic context when p=
erfect forwardin us used a pain. I propose to set of methods to look like:<=
br>&nbsp;  T&amp; value() &amp;;<br>&nbsp; T const&amp; value() const &amp;=
;<br>&nbsp; T&amp;&amp; value() &amp;&amp;;<br>&nbsp;To achieve consistency=
 with std::get function or even simple meber acces with procudes same cateo=
gry value for subobject.<br><br>If the original set&nbsp; of the methods wa=
s:<br>&nbsp; T&nbsp; value() const;<br>I would arrge tthe the new function =
should be declared as:<br>&nbsp; T&nbsp; value() const;<br>&nbsp; T&nbsp; v=
alue() &amp;&amp;;<br>But this is not <br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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_82_21799650.1404984557394--

.

--Apple-Mail=_B46A0D6D-F4A5-4917-8000-88BB4C0A21D4
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1


On 2014-07-10, at 5:29 PM, tomaszkam@gmail.com wrote:

> Which makes following invoaction f(expr.value()) where takes T by const& =
and expr is value of type optional<T>, introducing has additonal possibly-c=
opy dependin on expr being lvalue or r-value. And makes using optional in g=
eneric context when perfect forwardin us used a pain. I propose to set of m=
ethods to look like:
>   T& value() &;
>   T const& value() const &;
>   T&& value() &&;
>  To achieve consistency with std::get function or even simple meber acces=
 with procudes same cateogry value for subobject.

Here's the issue: std::get cannot reliably produce the same value category =
as a simple member access, because functions (in C++11, at least) cannot di=
stinguish xvalue arguments from prvalues. A member access on a prvalue prod=
uces a prvalue, but a member access get< N >( prvalue() ).mem produces an x=
value.

Why not put the adjustment into the forwarding function itself?

template< typename owner_type, typename value_type >
std::enable_if_t< std::is_lvalue_reference< owner_type >::value,
    value_type & >
forward_component( value_type & v )
    { return v; } // Container passed as lvalue yields a reference to lvalu=
e.

template< typename owner_type, typename value_type >
std::enable_if_t< ! std::is_lvalue_reference< owner_type >::value,
    value_type && >
forward_component( value_type & v )
    { return std::move( v ); } // Container passed as prvalue or xvalue yie=
lds xvalue.

Usage in the example context:

  return u ? std::forward<FV>(fv)(forward_component<U>(*u)) : std::forward<=
FN>(fn);

forward_component trusts the user that the function argument is owned by an=
 object of the template argument type. It handles vector::front and unique_=
ptr::operator* with equal aplomb, and we don't even have to add rvalue refe=
rence overloads to anything. (Although doing so may still be a good idea.)

> If the original set  of the methods was:
>   T  value() const;
> I would arrge tthe the new function should be declared as:
>   T  value() const;
>   T  value() &&;
> But this is not=20

?

By the way, you might as well keep the const && overload. "&&" and "const &=
&" usually have identical semantics. It is possible to have an expression o=
f const class 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/.

--Apple-Mail=_B46A0D6D-F4A5-4917-8000-88BB4C0A21D4
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014&=
ndash;07&ndash;10, at 5:29 PM, <a href=3D"mailto:tomaszkam@gmail.com">tomas=
zkam@gmail.com</a> wrote:</div><br><blockquote type=3D"cite"><div dir=3D"lt=
r">Which makes following invoaction f(expr.value()) where takes T by const&=
amp; and expr is value of type optional&lt;T&gt;, introducing has additonal=
 possibly-copy dependin on expr being lvalue or r-value. And makes using op=
tional in generic context when perfect forwardin us used a pain. I propose =
to set of methods to look like:<br>&nbsp;  T&amp; value() &amp;;<br>&nbsp; =
T const&amp; value() const &amp;;<br>&nbsp; T&amp;&amp; value() &amp;&amp;;=
<br>&nbsp;To achieve consistency with std::get function or even simple mebe=
r acces with procudes same cateogry value for subobject.<br></div></blockqu=
ote><div><br></div><div>Here&rsquo;s the issue: std::get cannot reliably pr=
oduce the same value category as a simple member access, because functions =
(in C++11, at least) cannot distinguish xvalue arguments from prvalues. A m=
ember access on a prvalue produces a prvalue, but a member access&nbsp;<fon=
t face=3D"Courier">get&lt; N &gt;( prvalue() ).mem</font>&nbsp;produces an =
xvalue.</div><div><br></div><div>Why not put the adjustment into the forwar=
ding function itself?</div><div><br></div><div><font face=3D"Courier">templ=
ate&lt; typename owner_type, typename value_type &gt;</font></div><div><fon=
t face=3D"Courier">std::enable_if_t&lt; std::is_lvalue_reference&lt;&nbsp;<=
/font><span style=3D"font-family: Courier;">owner_type</span><font face=3D"=
Courier">&nbsp;&gt;::value,</font></div><div><font face=3D"Courier">&nbsp; =
&nbsp; value_type &amp; &gt;</font></div><div><font face=3D"Courier">forwar=
d_component( value_type &amp; v )</font></div><div><font face=3D"Courier">&=
nbsp; &nbsp; { return v; } // Container passed as lvalue yields a reference=
 to lvalue.</font></div><div><font face=3D"Courier"><br></font></div><div><=
div><font face=3D"Courier">template&lt; typename owner_type, typename value=
_type &gt;</font></div><div><font face=3D"Courier">std::enable_if_t&lt; ! s=
td::is_lvalue_reference&lt;&nbsp;</font><span style=3D"font-family: Courier=
;">owner_type</span><font face=3D"Courier">&nbsp;&gt;::value,</font></div><=
div><font face=3D"Courier">&nbsp; &nbsp; value_type &amp;&amp; &gt;</font><=
/div><div><font face=3D"Courier">forward_component( value_type &amp; v )</f=
ont></div><div><font face=3D"Courier">&nbsp; &nbsp; { return std::move( v )=
; } // Container passed as prvalue or xvalue yields xvalue.</font></div><di=
v><br></div><div>Usage in the example context:</div><div><br></div><div><fo=
nt face=3D"Courier">&nbsp; return u ? std::forward&lt;FV&gt;(fv)(forward_co=
mponent&lt;U&gt;(*u)) : std::forward&lt;FN&gt;(fn);</font></div><div><br></=
div><div><font face=3D"Courier">forward_component</font> trusts the user th=
at the function argument is owned by an object of the template argument typ=
e. It handles <font face=3D"Courier">vector::front</font>&nbsp;and <font fa=
ce=3D"Courier">unique_ptr::operator*</font> with equal aplomb, and we don&r=
squo;t even have to add rvalue reference overloads to anything. (Although d=
oing so may still be a good idea.)</div><div><br></div></div><blockquote ty=
pe=3D"cite"><div dir=3D"ltr">If the original set&nbsp; of the methods was:<=
br>&nbsp; T&nbsp; value() const;<br>I would arrge tthe the new function sho=
uld be declared as:<br>&nbsp; T&nbsp; value() const;<br>&nbsp; T&nbsp; valu=
e() &amp;&amp;;<br>But this is not <br></div></blockquote><br></div><div>?<=
/div><div><br></div><div>By the way, you might as well keep the <font face=
=3D"Courier">const &amp;&amp;</font>&nbsp;overload. &ldquo;<font face=3D"Co=
urier">&amp;&amp;</font>&rdquo; and &ldquo;<font face=3D"Courier">const &am=
p;&amp;</font>&rdquo; usually have identical semantics. It is possible to h=
ave an expression of const class type.</div><div><br></div></body></html>

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

--Apple-Mail=_B46A0D6D-F4A5-4917-8000-88BB4C0A21D4--

.

------=_Part_49_17651027.1404987890892
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



W dniu czwartek, 10 lipca 2014 12:00:56 UTC+2 u=C5=BCytkownik David Krauss=
=20
napisa=C5=82:
>
>
> On 2014=E2=80=9307=E2=80=9310, at 5:29 PM, toma...@gmail.com <javascript:=
> wrote:
>
> Which makes following invoaction f(expr.value()) where takes T by const&=
=20
> and expr is value of type optional<T>, introducing has additonal=20
> possibly-copy dependin on expr being lvalue or r-value. And makes using=
=20
> optional in generic context when perfect forwardin us used a pain. I=20
> propose to set of methods to look like:
>   T& value() &;
>   T const& value() const &;
>   T&& value() &&;
>  To achieve consistency with std::get function or even simple meber acces=
=20
> with procudes same cateogry value for subobject.
>
>
> Here=E2=80=99s the issue: std::get cannot reliably produce the same value=
 category=20
> as a simple member access, because functions (in C++11, at least) cannot=
=20
> distinguish xvalue arguments from prvalues. A member access on a prvalue=
=20
> produces a prvalue, but a member access get< N >( prvalue() ).mem produce=
s=20
> an xvalue.
>
> Why not put the adjustment into the forwarding function itself?
>
> template< typename owner_type, typename value_type >
> std::enable_if_t< std::is_lvalue_reference< owner_type >::value,
>     value_type & >
> forward_component( value_type & v )
>     { return v; } // Container passed as lvalue yields a reference to=20
> lvalue.
>
> template< typename owner_type, typename value_type >
> std::enable_if_t< ! std::is_lvalue_reference< owner_type >::value,
>     value_type && >
> forward_component( value_type & v )
>     { return std::move( v ); } // Container passed as prvalue or xvalue=
=20
> yields xvalue.
>
> Usage in the example context:
>
>   return u ? std::forward<FV>(fv)(forward_component<U>(*u)) :=20
> std::forward<FN>(fn);
>
> forward_component trusts the user that the function argument is owned by=
=20
> an object of the template argument type. It handles vector::front and=20
> unique_ptr::operator* with equal aplomb, and we don=E2=80=99t even have t=
o add=20
> rvalue reference overloads to anything. (Although doing so may still be a=
=20
> good idea.)
>

And this wis actually break every use of forward with non-owning semenatics=
=20
(shared_ptr<T>). Please remember that forward function was designed to=20
perfectly forward value of any type in generic context without=20
introspection, but introducing separate forward_compoent kills the idea,=20
because we me differentiate between shared_ptr and unique_ptr.

Acutally defininig the rvalue reference overload for member getters=20
returning rvalue reference (T&& meber() &&) is the way a type can=20
signialize to forward that it owning this member. That means we could have:
T&& operator*() &&; //for unique_ptr, bot not for shared_ptr
Or for vector<T>:
T&& front() &&;
T&& back() &&;
Or even for begin/end members that will allows us to have better=20
traversable constructor:=20
https://groups.google.com/a/isocpp.org/forum/?fromgroups#!topic/std-proposa=
ls/sOw68ogy6BM

If the original set  of the methods was:
>   T  value() const;
> I would argee tthe the new function should be declared as:
>   T  value() const &;
>   T  value() &&;
> But this is not true in the case of optional. And also not having safe=20
> version of operator* , that will allow you to modyfy value inplace, would=
=20
> be a failure. Maybe the name is wrong.
>
> ?
>
> By the way, you might as well keep the const && overload. =E2=80=9C&&=E2=
=80=9D and =E2=80=9Cconst=20
> &&=E2=80=9D usually have identical semantics. It is possible to have an=
=20
> expression of const class type.
>
> Now const&& should have the same semenantics as the const& so the additio=
n=20
overload is not neccessary.=20
=20

--=20

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

------=_Part_49_17651027.1404987890892
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>W dniu czwartek, 10 lipca 2014 12:00:56 UTC+2 u=C5=
=BCytkownik David Krauss napisa=C5=82:<blockquote class=3D"gmail_quote" sty=
le=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left=
: 1ex;"><div style=3D"word-wrap:break-word"><br><div><div>On 2014=E2=80=930=
7=E2=80=9310, at 5:29 PM, <a href=3D"javascript:" target=3D"_blank" gdf-obf=
uscated-mailto=3D"hCccXhJmq3sJ" onmousedown=3D"this.href=3D'javascript:';re=
turn true;" onclick=3D"this.href=3D'javascript:';return true;">toma...@gmai=
l.com</a> wrote:</div><br><blockquote type=3D"cite"><div dir=3D"ltr">Which =
makes following invoaction f(expr.value()) where takes T by const&amp; and =
expr is value of type optional&lt;T&gt;, introducing has additonal possibly=
-copy dependin on expr being lvalue or r-value. And makes using optional in=
 generic context when perfect forwardin us used a pain. I propose to set of=
 methods to look like:<br>&nbsp;  T&amp; value() &amp;;<br>&nbsp; T const&a=
mp; value() const &amp;;<br>&nbsp; T&amp;&amp; value() &amp;&amp;;<br>&nbsp=
;To achieve consistency with std::get function or even simple meber acces w=
ith procudes same cateogry value for subobject.<br></div></blockquote><div>=
<br></div><div>Here=E2=80=99s the issue: std::get cannot reliably produce t=
he same value category as a simple member access, because functions (in C++=
11, at least) cannot distinguish xvalue arguments from prvalues. A member a=
ccess on a prvalue produces a prvalue, but a member access&nbsp;<font face=
=3D"Courier">get&lt; N &gt;( prvalue() ).mem</font>&nbsp;produces an xvalue=
..</div><div><br></div><div>Why not put the adjustment into the forwarding f=
unction itself?</div><div><br></div><div><font face=3D"Courier">template&lt=
; typename owner_type, typename value_type &gt;</font></div><div><font face=
=3D"Courier">std::enable_if_t&lt; std::is_lvalue_reference&lt;&nbsp;</font>=
<span style=3D"font-family:Courier">owne<wbr>r_type</span><font face=3D"Cou=
rier">&nbsp;&gt;::value,</font></div><div><font face=3D"Courier">&nbsp; &nb=
sp; value_type &amp; &gt;</font></div><div><font face=3D"Courier">forward_c=
omponent( value_type &amp; v )</font></div><div><font face=3D"Courier">&nbs=
p; &nbsp; { return v; } // Container passed as lvalue yields a reference to=
 lvalue.</font></div><div><font face=3D"Courier"><br></font></div><div styl=
e=3D"word-wrap:break-word"><div><font face=3D"Courier">template&lt; typenam=
e owner_type, typename value_type &gt;</font></div><div><font face=3D"Couri=
er">std::enable_if_t&lt; ! std::is_lvalue_reference&lt;&nbsp;</font><span s=
tyle=3D"font-family:Courier">owne<wbr>r_type</span><font face=3D"Courier">&=
nbsp;&gt;::value,</font></div><div><font face=3D"Courier">&nbsp; &nbsp; val=
ue_type &amp;&amp; &gt;</font></div><div><font face=3D"Courier">forward_com=
ponent( value_type &amp; v )</font></div><div><font face=3D"Courier">&nbsp;=
 &nbsp; { return std::move( v ); } // Container passed as prvalue or xvalue=
 yields xvalue.</font></div><div><br></div><div>Usage in the example contex=
t:</div><div><br></div><div><font face=3D"Courier">&nbsp; return u ? std::f=
orward&lt;FV&gt;(fv)(forward_<wbr>component&lt;U&gt;(*u)) : std::forward&lt=
;FN&gt;(fn);</font></div><div><br></div><div><font face=3D"Courier">forward=
_component</font> trusts the user that the function argument is owned by an=
 object of the template argument type. It handles <font face=3D"Courier">ve=
ctor::front</font>&nbsp;and <font face=3D"Courier">unique_ptr::operator*</f=
ont> with equal aplomb, and we don=E2=80=99t even have to add rvalue refere=
nce overloads to anything. (Although doing so may still be a good idea.)<br=
></div></div></div></div></blockquote><div><br>And this wis actually break =
every use of forward with non-owning semenatics (shared_ptr&lt;T&gt;). Plea=
se remember that forward function was designed to perfectly forward value o=
f any type in generic context without introspection, but introducing separa=
te forward_compoent kills the idea, because we me differentiate between sha=
red_ptr and unique_ptr.<br><br>Acutally defininig the rvalue reference over=
load for member getters returning rvalue reference (T&amp;&amp; meber() &am=
p;&amp;) is the way a type can signialize to forward that it owning this me=
mber. That means we could have:<br>T&amp;&amp; operator*() &amp;&amp;; //fo=
r unique_ptr, bot not for shared_ptr<br>Or for vector&lt;T&gt;:<br>T&amp;&a=
mp; front() &amp;&amp;;<br>T&amp;&amp; back() &amp;&amp;;<br>Or even for be=
gin/end members that will allows us to have better traversable constructor:=
 https://groups.google.com/a/isocpp.org/forum/?fromgroups#!topic/std-propos=
als/sOw68ogy6BM<br><div><br></div><div><blockquote class=3D"gmail_quote" st=
yle=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-lef=
t: 1ex;"><div style=3D"word-wrap:break-word"><div><blockquote type=3D"cite"=
><div dir=3D"ltr">If the original set&nbsp; of the methods was:<br>&nbsp; T=
&nbsp; value() const;<br>I would argee tthe the new function should be decl=
ared as:<br>&nbsp; T&nbsp; value() const &amp;;<br>&nbsp; T&nbsp; value() &=
amp;&amp;;<br>But this is not true in the case of optional. And also not ha=
ving safe version of operator* , that will allow you to modyfy value inplac=
e, would be a failure. Maybe the name is wrong.<br></div></blockquote></div=
><div>?</div><div><br></div><div>By the way, you might as well keep the <fo=
nt face=3D"Courier">const &amp;&amp;</font>&nbsp;overload. =E2=80=9C<font f=
ace=3D"Courier">&amp;&amp;</font>=E2=80=9D and =E2=80=9C<font face=3D"Couri=
er">const &amp;&amp;</font>=E2=80=9D usually have identical semantics. It i=
s possible to have an expression of const class type.</div><div><br></div><=
/div></blockquote>Now const&amp;&amp; should have the same semenantics as t=
he const&amp; so the addition overload is not neccessary. </div>&nbsp;</div=
></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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_49_17651027.1404987890892--

.

--Apple-Mail=_E9E7CE9F-821B-476B-9720-FAD3FC0F878E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8


On 2014=E2=80=9307=E2=80=9310, at 6:24 PM, tomaszkam@gmail.com wrote:

> W dniu czwartek, 10 lipca 2014 12:00:56 UTC+2 u=C5=BCytkownik David Kraus=
s napisa=C5=82:
>=20
> forward_component trusts the user that the function argument is owned by =
an object of the template argument type. It handles vector::front and uniqu=
e_ptr::operator* with equal aplomb, and we don=E2=80=99t even have to add r=
value reference overloads to anything. (Although doing so may still be a go=
od idea.)
>=20
> And this wis actually break every use of forward with non-owning semenati=
cs (shared_ptr<T>). Please remember that forward function was designed to p=
erfectly forward value of any type in generic context without introspection=
, but introducing separate forward_compoent kills the idea, because we me d=
ifferentiate between shared_ptr and unique_ptr.

Shared ownership fails to satisfy the stated requirement. No suitable forwa=
rding semantics exist for shared_ptr, and the value category of the pointer=
 carries no information about the shared object. You just have to assume th=
at it=E2=80=99s not-owned, unless shared_ptr::unique returns true, in which=
 case forward_component works.

No =E2=80=9Cgeneric context=E2=80=9D can handle different pointer types. un=
ique_ptr<T> always owns its referent but T* never does. You seem to suggest=
 I=E2=80=99ve =E2=80=9Ckilled=E2=80=9D an alternative that never existed in=
 the first place.

Yes, it=E2=80=99s impossible to call make_shared, destroy the sharing pool,=
 and still safely bind the erstwhile-shared value to a universal reference =
all in one declaration. This sounds pretty contrived, though. Use of shared=
_ptr at all implies that the object existed before the line in question, an=
d if you want to continue using a subobject after the line, don=E2=80=99t m=
ove() the shared_pointer.

> Acutally defininig the rvalue reference overload for member getters retur=
ning rvalue reference (T&& meber() &&) is the way a type can signialize to =
forward that it owning this member. That means we could have:
> T&& operator*() &&; //for unique_ptr, bot not for shared_ptr
> Or for vector<T>:
> T&& front() &&;
> T&& back() &&;
> Or even for begin/end members that will allows us to have better traversa=
ble constructor: https://groups.google.com/a/isocpp.org/forum/?fromgroups#!=
topic/std-proposals/sOw68ogy6BM

Yes, I mentioned that hypothetically to Ville. Considering the implementati=
on effort and added compilation complexity of that strategy, you might as w=
ell use forward_component() with no adjustment to the container (or plain-o=
ld move() when not forwarding).

> Now const&& should have the same semenantics as the const& so the additio=
n overload is not necessary.

Strange, I didn=E2=80=99t realize that const& is preferred over && for a co=
nst rvalue implicit argument, but so it is. GCC even fails to prefer const&=
& over const&.

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

--Apple-Mail=_E9E7CE9F-821B-476B-9720-FAD3FC0F878E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;"><br><div><div>On 2014=E2=80=
=9307=E2=80=9310, at 6:24 PM, <a href=3D"mailto:tomaszkam@gmail.com">tomasz=
kam@gmail.com</a> wrote:</div><br class=3D"Apple-interchange-newline"><bloc=
kquote type=3D"cite"><div dir=3D"ltr">W dniu czwartek, 10 lipca 2014 12:00:=
56 UTC+2 u=C5=BCytkownik David Krauss napisa=C5=82:<br><blockquote class=3D=
"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; border-left-width: 1px; b=
order-left-color: rgb(204, 204, 204); border-left-style: solid; padding-lef=
t: 1ex; position: static; z-index: auto;"><div style=3D"word-wrap:break-wor=
d"><br><div><div><font face=3D"Courier">forward_component</font> trusts the=
 user that the function argument is owned by an object of the template argu=
ment type. It handles <font face=3D"Courier">vector::front</font>&nbsp;and =
<font face=3D"Courier">unique_ptr::operator*</font> with equal aplomb, and =
we don=E2=80=99t even have to add rvalue reference overloads to anything. (=
Although doing so may still be a good idea.)</div></div></div></blockquote>=
<div><br>And this wis actually break every use of forward with non-owning s=
emenatics (shared_ptr&lt;T&gt;). Please remember that forward function was =
designed to perfectly forward value of any type in generic context without =
introspection, but introducing separate forward_compoent kills the idea, be=
cause we me differentiate between shared_ptr and unique_ptr.<br></div></div=
></blockquote><div><br></div><div>Shared ownership fails to satisfy the sta=
ted requirement. No suitable forwarding semantics exist for <font face=3D"C=
ourier">shared_ptr</font>, and the value category of the pointer carries no=
 information about the shared object. You just have to assume that it=E2=80=
=99s not-owned, unless <font face=3D"Courier">shared_ptr::unique</font> ret=
urns true, in which case <font face=3D"Courier">forward_component</font> wo=
rks.</div><div><br></div><div><div>No =E2=80=9Cgeneric context=E2=80=9D can=
 handle different pointer types.&nbsp;<font face=3D"Courier">unique_ptr&lt;=
T&gt;</font>&nbsp;always owns its referent but&nbsp;<font face=3D"Courier">=
T*</font>&nbsp;never does. You seem to suggest I=E2=80=99ve =E2=80=9Ckilled=
=E2=80=9D an alternative that never existed in the first place.</div><div><=
br></div></div><div>Yes, it=E2=80=99s impossible to call <font face=3D"Cour=
ier">make_shared</font>, destroy the sharing pool, and still safely bind th=
e erstwhile-shared value to a universal reference all in one declaration. T=
his sounds pretty contrived, though. Use of <font face=3D"Courier">shared_p=
tr</font> at all implies that the object existed before the line in questio=
n, and if you want to continue using a subobject after the line, don=E2=80=
=99t <font face=3D"Courier">move()</font> the <font face=3D"Courier">shared=
_pointer</font>.</div><div><br></div><blockquote type=3D"cite"><div dir=3D"=
ltr"><div>Acutally defininig the rvalue reference overload for member gette=
rs returning rvalue reference (T&amp;&amp; meber() &amp;&amp;) is the way a=
 type can signialize to forward that it owning this member. That means we c=
ould have:<br>T&amp;&amp; operator*() &amp;&amp;; //for unique_ptr, bot not=
 for shared_ptr<br>Or for vector&lt;T&gt;:<br>T&amp;&amp; front() &amp;&amp=
;;<br>T&amp;&amp; back() &amp;&amp;;<br>Or even for begin/end members that =
will allows us to have better traversable constructor: <a href=3D"https://g=
roups.google.com/a/isocpp.org/forum/?fromgroups#!topic/std-proposals/sOw68o=
gy6BM">https://groups.google.com/a/isocpp.org/forum/?fromgroups#!topic/std-=
proposals/sOw68ogy6BM</a><br></div></div></blockquote><div><br></div><div>Y=
es, I mentioned that hypothetically to Ville. Considering the implementatio=
n effort and added compilation complexity of that strategy, you might as we=
ll use <font face=3D"Courier">forward_component()</font>&nbsp;with no adjus=
tment to the container (or plain-old&nbsp;<font face=3D"Courier">move()</fo=
nt> when not forwarding).</div><br><blockquote type=3D"cite"><div dir=3D"lt=
r"><div>Now const&amp;&amp; should have the same semenantics as the const&a=
mp; so the addition overload is not necessary.</div></div></blockquote><div=
><br></div><div>Strange, I didn=E2=80=99t realize that <font face=3D"Courie=
r">const&amp;</font> is preferred over <font face=3D"Courier">&amp;&amp;</f=
ont> for a <font face=3D"Courier">const</font> rvalue implicit argument, bu=
t so it is. GCC even fails to prefer <font face=3D"Courier">const&amp;&amp;=
</font> over <font face=3D"Courier">const&amp;</font>.</div></div><br></bod=
y></html>

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

--Apple-Mail=_E9E7CE9F-821B-476B-9720-FAD3FC0F878E--

.

------=_Part_7_7260802.1404992569033
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



W dniu czwartek, 10 lipca 2014 13:12:57 UTC+2 u=C5=BCytkownik David Krauss=
=20
napisa=C5=82:
>
>
> On 2014=E2=80=9307=E2=80=9310, at 6:24 PM, toma...@gmail.com <javascript:=
> wrote:
>
> W dniu czwartek, 10 lipca 2014 12:00:56 UTC+2 u=C5=BCytkownik David Kraus=
s=20
> napisa=C5=82:
>
>>
>> forward_component trusts the user that the function argument is owned by=
=20
>> an object of the template argument type. It handles vector::front and=20
>> unique_ptr::operator* with equal aplomb, and we don=E2=80=99t even have =
to add=20
>> rvalue reference overloads to anything. (Although doing so may still be =
a=20
>> good idea.)
>>
>
> And this wis actually break every use of forward with non-owning=20
> semenatics (shared_ptr<T>). Please remember that forward function was=20
> designed to perfectly forward value of any type in generic context withou=
t=20
> introspection, but introducing separate forward_compoent kills the idea,=
=20
> because we me differentiate between shared_ptr and unique_ptr.
>
>
> Shared ownership fails to satisfy the stated requirement. No suitable=20
> forwarding semantics exist for shared_ptr, and the value category of the=
=20
> pointer carries no information about the shared object. You just have to=
=20
> assume that it=E2=80=99s not-owned, unless shared_ptr::unique returns tru=
e, in=20
> which case forward_component works.
>
> No =E2=80=9Cgeneric context=E2=80=9D can handle different pointer types. =
unique_ptr<T> always=20
> owns its referent but T* never does. You seem to suggest I=E2=80=99ve =E2=
=80=9Ckilled=E2=80=9D an=20
> alternative that never existed in the first place.
>
> Yes, it=E2=80=99s impossible to call make_shared, destroy the sharing poo=
l, and=20
> still safely bind the erstwhile-shared value to a universal reference all=
=20
> in one declaration. This sounds pretty contrived, though. Use of=20
> shared_ptr at all implies that the object existed before the line in=20
> question, and if you want to continue using a subobject after the line,=
=20
> don=E2=80=99t move() the shared_pointer.
>
> Acutally defininig the rvalue reference overload for member getters=20
> returning rvalue reference (T&& meber() &&) is the way a type can=20
> signialize to forward that it owning this member. That means we could hav=
e:
> T&& operator*() &&; //for unique_ptr, bot not for shared_ptr
> Or for vector<T>:
> T&& front() &&;
> T&& back() &&;
> Or even for begin/end members that will allows us to have better=20
> traversable constructor:=20
> https://groups.google.com/a/isocpp.org/forum/?fromgroups#!topic/std-propo=
sals/sOw68ogy6BM
>
>
> Yes, I mentioned that hypothetically to Ville. Considering the=20
> implementation effort and added compilation complexity of that strategy,=
=20
> you might as well use forward_component() with no adjustment to the=20
> container (or plain-old move() when not forwarding).
>
> Now const&& should have the same semenantics as the const& so the additio=
n=20
> overload is not necessary.
>
>
> Strange, I didn=E2=80=99t realize that const& is preferred over && for a =
const=20
> rvalue implicit argument, but so it is. GCC even fails to prefer const&&=
=20
> over const&.
>


My point is that with the montions that will begin with having T&&=20
value()&& method we can start a montion to make following code:
template<typename Nullable>
void f(Nullable&& n)
{
   foo(*std::forward<Nullable>(n));
};
To pass an T&& if Nullable&& is optional<T>&& and pass reference=20
(optionally) const for shared_ptr<T>, unique_ptr<T>, T*. If we add then T&&=
=20
operator*() &&; for unique_ptr<T> to represent ownership.
Then we will have at least one case handled in the forward correclty.=20

In think that the class should definie if it have ownership over member *by=
=20
definining r-value overload) and this should not be handled on the invoker=
=20
side, by requring using forward_component or move. This also brakes=20
encapsulation.=20

If we have methods (T&& operator*() && for unique_ptr<T> and optional<T>,=
=20
but not for shared_ptr<T> and of course T&&) metonied above the expression=
=20
*std::forward<Nullable>(n) will do the right thing and not forward_compoent=
=20
being necessary. If we go with the T value()&& in the current sementic of=
=20
value() method (giving acces to stored value, not returning value) we will=
=20
close this way.

I think that library should be make easier to use at cost of it complexlity=
=20
and having *std::forward<Nullable>(n) do the right think (at least for=20
optional) instead of requirng separte handling of owning/non-owning=20
nullables. Also the r-value overloaded method/function approach is more=20
extensible for user defined classes, because we need some kind of way to=20
determine user-definied class owns specific member (they may be many of=20
them) and forward or forward_component should be used. I think that=20
overloading is a think simplest way.

Meybe we need some king od language mechanism to define following set of=20
members:
  T&& mem() &&;
  T& mem()&;
  T const& mem() const&;

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

<div dir=3D"ltr"><br><br>W dniu czwartek, 10 lipca 2014 13:12:57 UTC+2 u=C5=
=BCytkownik David Krauss napisa=C5=82:<blockquote class=3D"gmail_quote" sty=
le=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left=
: 1ex;"><div style=3D"word-wrap:break-word"><br><div><div>On 2014=E2=80=930=
7=E2=80=9310, at 6:24 PM, <a href=3D"javascript:" target=3D"_blank" gdf-obf=
uscated-mailto=3D"mery1kCKd0wJ" onmousedown=3D"this.href=3D'javascript:';re=
turn true;" onclick=3D"this.href=3D'javascript:';return true;">toma...@gmai=
l.com</a> wrote:</div><br><blockquote type=3D"cite"><div dir=3D"ltr">W dniu=
 czwartek, 10 lipca 2014 12:00:56 UTC+2 u=C5=BCytkownik David Krauss napisa=
=C5=82:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.=
8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-st=
yle:solid;padding-left:1ex"><div style=3D"word-wrap:break-word"><br><div><d=
iv><font face=3D"Courier">forward_component</font> trusts the user that the=
 function argument is owned by an object of the template argument type. It =
handles <font face=3D"Courier">vector::front</font>&nbsp;and <font face=3D"=
Courier">unique_ptr::operator*</font> with equal aplomb, and we don=E2=80=
=99t even have to add rvalue reference overloads to anything. (Although doi=
ng so may still be a good idea.)</div></div></div></blockquote><div><br>And=
 this wis actually break every use of forward with non-owning semenatics (s=
hared_ptr&lt;T&gt;). Please remember that forward function was designed to =
perfectly forward value of any type in generic context without introspectio=
n, but introducing separate forward_compoent kills the idea, because we me =
differentiate between shared_ptr and unique_ptr.<br></div></div></blockquot=
e><div><br></div><div>Shared ownership fails to satisfy the stated requirem=
ent. No suitable forwarding semantics exist for <font face=3D"Courier">shar=
ed_ptr</font>, and the value category of the pointer carries no information=
 about the shared object. You just have to assume that it=E2=80=99s not-own=
ed, unless <font face=3D"Courier">shared_ptr::unique</font> returns true, i=
n which case <font face=3D"Courier">forward_component</font> works.</div><d=
iv><br></div><div><div>No =E2=80=9Cgeneric context=E2=80=9D can handle diff=
erent pointer types.&nbsp;<font face=3D"Courier">unique_ptr&lt;T&gt;</font>=
&nbsp;always owns its referent but&nbsp;<font face=3D"Courier">T*</font>&nb=
sp;never does. You seem to suggest I=E2=80=99ve =E2=80=9Ckilled=E2=80=9D an=
 alternative that never existed in the first place.</div><div><br></div></d=
iv><div>Yes, it=E2=80=99s impossible to call <font face=3D"Courier">make_sh=
ared</font>, destroy the sharing pool, and still safely bind the erstwhile-=
shared value to a universal reference all in one declaration. This sounds p=
retty contrived, though. Use of <font face=3D"Courier">shared_ptr</font> at=
 all implies that the object existed before the line in question, and if yo=
u want to continue using a subobject after the line, don=E2=80=99t <font fa=
ce=3D"Courier">move()</font> the <font face=3D"Courier">shared_pointer</fon=
t>.</div><div><br></div><blockquote type=3D"cite"><div dir=3D"ltr"><div>Acu=
tally defininig the rvalue reference overload for member getters returning =
rvalue reference (T&amp;&amp; meber() &amp;&amp;) is the way a type can sig=
nialize to forward that it owning this member. That means we could have:<br=
>T&amp;&amp; operator*() &amp;&amp;; //for unique_ptr, bot not for shared_p=
tr<br>Or for vector&lt;T&gt;:<br>T&amp;&amp; front() &amp;&amp;;<br>T&amp;&=
amp; back() &amp;&amp;;<br>Or even for begin/end members that will allows u=
s to have better traversable constructor: <a href=3D"https://groups.google.=
com/a/isocpp.org/forum/?fromgroups#!topic/std-proposals/sOw68ogy6BM" target=
=3D"_blank" onmousedown=3D"this.href=3D'https://groups.google.com/a/isocpp.=
org/forum/?fromgroups#!topic/std-proposals/sOw68ogy6BM';return true;" oncli=
ck=3D"this.href=3D'https://groups.google.com/a/isocpp.org/forum/?fromgroups=
#!topic/std-proposals/sOw68ogy6BM';return true;">https://groups.google.com/=
a/<wbr>isocpp.org/forum/?fromgroups#!<wbr>topic/std-proposals/<wbr>sOw68ogy=
6BM</a><br></div></div></blockquote><div><br></div><div>Yes, I mentioned th=
at hypothetically to Ville. Considering the implementation effort and added=
 compilation complexity of that strategy, you might as well use <font face=
=3D"Courier">forward_component()</font>&nbsp;with no adjustment to the cont=
ainer (or plain-old&nbsp;<font face=3D"Courier">move()</font> when not forw=
arding).</div><br><blockquote type=3D"cite"><div dir=3D"ltr"><div>Now const=
&amp;&amp; should have the same semenantics as the const&amp; so the additi=
on overload is not necessary.</div></div></blockquote><div><br></div><div>S=
trange, I didn=E2=80=99t realize that <font face=3D"Courier">const&amp;</fo=
nt> is preferred over <font face=3D"Courier">&amp;&amp;</font> for a <font =
face=3D"Courier">const</font> rvalue implicit argument, but so it is. GCC e=
ven fails to prefer <font face=3D"Courier">const&amp;&amp;</font> over <fon=
t face=3D"Courier">const&amp;</font>.</div></div></div></blockquote><div><b=
r><br>My point is that with the montions that will begin with having T&amp;=
&amp; value()&amp;&amp; method we can start a montion to make following cod=
e:<br>template&lt;typename Nullable&gt;<br>void f(Nullable&amp;&amp; n)<br>=
{<br>&nbsp;&nbsp; foo(*std::forward&lt;Nullable&gt;(n));<br>};<br>To pass a=
n T&amp;&amp; if Nullable&amp;&amp; is optional&lt;T&gt;&amp;&amp; and pass=
 reference (optionally) const for shared_ptr&lt;T&gt;, unique_ptr&lt;T&gt;,=
 T*. If we add then T&amp;&amp; operator*() &amp;&amp;; for unique_ptr&lt;T=
&gt; to represent ownership.<br>Then we will have at least one case handled=
 in the forward correclty. <br><font face=3D"Courier"><br></font>In think t=
hat the class should definie if it have ownership over member *by defininin=
g r-value overload) and this should not be handled on the invoker side, by =
requring using forward_component or move. This also brakes encapsulation. <=
br><br>If we have methods (T&amp;&amp; operator*() &amp;&amp; for unique_pt=
r&lt;T&gt; and optional&lt;T&gt;, but not for shared_ptr&lt;T&gt; and of co=
urse T&amp;&amp;) metonied above the expression *std::forward&lt;Nullable&g=
t;(n) will do the right thing and not forward_compoent being necessary. If =
we go with the T value()&amp;&amp; in the current sementic of value() metho=
d (giving acces to stored value, not returning value)=20
we will close this way.<br><br>I think that library should be make easier t=
o use at cost of it complexlity and having *std::forward&lt;Nullable&gt;(n)=
 do the right think (at least for optional) instead of requirng separte han=
dling of owning/non-owning nullables. Also the r-value overloaded method/fu=
nction approach is more extensible for user defined classes, because we nee=
d some kind of way to determine user-definied class owns specific member (t=
hey may be many of them) and forward or forward_component should be used. I=
 think that overloading is a think simplest way.<br><br>Meybe we need some =
king od language mechanism to define following set of members:<br>&nbsp; T&=
amp;&amp; mem() &amp;&amp;;<br>&nbsp; T&amp; mem()&amp;;<br>&nbsp; T const&=
amp; mem() const&amp;;<br><br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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_7_7260802.1404992569033--

.

On 10 July 2014 12:03, David Krauss <potswa@gmail.com> wrote:
>
> On 2014=E2=80=9307=E2=80=9310, at 5:01 PM, Ville Voutilainen <ville.vouti=
lainen@gmail.com>
> wrote:
>
> On 10 July 2014 11:58, David Krauss <potswa@gmail.com> wrote:
>
> Risky micro-optimization should never be the default. If
>
>
> It's not a micro-optimization.
>
>
> Eliminating one move is a micro-optimization.

No it is not. For legacy types with user-provided copy operations or a
user-provided
destructor, that move is a copy. It is not a micro-optimization
regardless of how
many times you want to repeat your uneducated position.

The rvalue-ref-qualified signatures need to return T&& instead of T.
LEWG needs an NB comment
to be able to make that fix for Fundamentals v1, and I'm going to provide t=
hem
with one.

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

.

--Apple-Mail=_6826AD23-444E-409B-8102-3A2BD68F6BC0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1


On 2014-07-10, at 9:25 PM, Ville Voutilainen <ville.voutilainen@gmail.com> =
wrote:

> No it is not. For legacy types with user-provided copy operations or a
> user-provided
> destructor, that move is a copy. It is not a micro-optimization
> regardless of how
> many times you want to repeat your uneducated position.

I'd be happy to read any background info that's available. I still can't ac=
cess isocpp.org (as I often can't, I wish that weren't hosting a bugtracker=
) but I'll read up when it becomes reachable again from my ISP.

A return-by-reference from a non-ref-discriminated accessor devolving to re=
turn-by-copy would regress legacy code, but that doesn't make such library =
behavior semantically sound from a modern point of view.

> The rvalue-ref-qualified signatures need to return T&& instead of T.
> LEWG needs an NB comment
> to be able to make that fix for Fundamentals v1, and I'm going to provide=
 them
> with one.

The rvalue-ref-qualified signatures of what, std::optional? That's not a re=
gression then, because no legacy code is written against std::optional. No =
smart pointer or container has such rvalue-ref-qualified accessors in C++14=
 nor the latest Fundamentals TS draft on GitHub. (That draft also doesn't m=
ention rref-qualified optional::value, although value_or does discriminate.=
)

I'll read whatever background I can, but unless something stronger "educate=
s" my current position, I think I'd prefer to formalize the arguments for r=
eturn-by-value providing greater consistency. I'm sorry for having missed t=
he debate so far and being so ignorant, but this process is public to encou=
rage thorough review.

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

--Apple-Mail=_6826AD23-444E-409B-8102-3A2BD68F6BC0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014&=
ndash;07&ndash;10, at 9:25 PM, Ville Voutilainen &lt;<a href=3D"mailto:vill=
e.voutilainen@gmail.com">ville.voutilainen@gmail.com</a>&gt; wrote:</div><b=
r class=3D"Apple-interchange-newline"><blockquote type=3D"cite">No it is no=
t. For legacy types with user-provided copy operations or a<br>user-provide=
d<br>destructor, that move is a copy. It is not a micro-optimization<br>reg=
ardless of how<br>many times you want to repeat your uneducated position.<b=
r></blockquote><div><br></div><div>I&rsquo;d be happy to read any backgroun=
d info that&rsquo;s available. I still can&rsquo;t access <a href=3D"http:/=
/isocpp.org">isocpp.org</a> (as I often can&rsquo;t, I wish that weren&rsqu=
o;t hosting a bugtracker) but I&rsquo;ll read up when it becomes reachable =
again from my ISP.</div><div><br></div><div>A return-by-reference from a no=
n-ref-discriminated accessor devolving to return-by-copy would regress lega=
cy code, but that doesn&rsquo;t make such library behavior semantically sou=
nd from a modern point of view.</div><div><br></div><blockquote type=3D"cit=
e">The rvalue-ref-qualified signatures need to return T&amp;&amp; instead o=
f T.<br>LEWG needs an NB comment<br>to be able to make that fix for Fundame=
ntals v1, and I'm going to provide them<br>with one.<br></blockquote><div><=
br></div><div>The rvalue-ref-qualified signatures of what, <font face=3D"Co=
urier">std::optional</font>? That&rsquo;s not a regression then, because no=
 legacy code is written against std::optional. No smart pointer or containe=
r has such rvalue-ref-qualified accessors in C++14 nor the latest Fundament=
als TS draft on GitHub. (That draft also doesn&rsquo;t mention rref-qualifi=
ed <font face=3D"Courier">optional::value</font>, although <font face=3D"Co=
urier">value_or</font> does discriminate.)</div><div><br></div><div>I&rsquo=
;ll read whatever background I can, but unless something stronger &ldquo;ed=
ucates&rdquo; my current position, I think I&rsquo;d prefer to formalize th=
e arguments for return-by-value providing greater consistency. I&rsquo;m so=
rry for having missed the debate so far and being so ignorant, but this pro=
cess is public to encourage thorough review.</div><div><br></div></div></bo=
dy></html>

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

--Apple-Mail=_6826AD23-444E-409B-8102-3A2BD68F6BC0--

.

On 10 July 2014 17:24, David Krauss <potswa@gmail.com> wrote:
> A return-by-reference from a non-ref-discriminated accessor devolving to
> return-by-copy would regress legacy code, but that doesn=E2=80=99t make s=
uch library
> behavior semantically sound from a modern point of view.

The "modern point of view" should include the forwarding concerns, which
are not limited to the performance of emplace.

> The rvalue-ref-qualified signatures need to return T&& instead of T.
> LEWG needs an NB comment
> to be able to make that fix for Fundamentals v1, and I'm going to provide
> them
> with one.
>
>
> The rvalue-ref-qualified signatures of what, std::optional? That=E2=80=99=
s not a

Uh.. yes. That's the topic of this thread.

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

.

--Apple-Mail=_36C7DCE8-AF9A-4998-B313-76D861386C7E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1


On 2014-07-10, at 10:44 PM, Ville Voutilainen <ville.voutilainen@gmail.com>=
 wrote:

> On 10 July 2014 17:24, David Krauss <potswa@gmail.com> wrote:
>> A return-by-reference from a non-ref-discriminated accessor devolving to
>> return-by-copy would regress legacy code, but that doesn't make such lib=
rary
>> behavior semantically sound from a modern point of view.
>=20
> The "modern point of view" should include the forwarding concerns, which
> are not limited to the performance of emplace.

Absolutely. I'm have an interest in this because I write this kind of code.

>> The rvalue-ref-qualified signatures need to return T&& instead of T.
>> LEWG needs an NB comment
>> to be able to make that fix for Fundamentals v1, and I'm going to provid=
e
>> them
>> with one.
>>=20
>>=20
>> The rvalue-ref-qualified signatures of what, std::optional? That's not a
>=20
> Uh.. yes. That's the topic of this thread.

Maybe I don't understand the standardization process, but wouldn't the cons=
ervative solution be to simply roll that back from N4078, so optional behav=
es the same as everything else? Adding a new feature in a particular way do=
esn't fall into the category of legacy support.

Optional is attempting to be the most perfect proxy class ever designed, an=
d it's pushing the envelope in a way that fundamentally disagrees with stan=
dardization. Simply put, it's churning too much.

The debate can't be just about optional, even just in this thread, because =
the rest of the library is going to have to follow suit.

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

--Apple-Mail=_36C7DCE8-AF9A-4998-B313-76D861386C7E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014&=
ndash;07&ndash;10, at 10:44 PM, Ville Voutilainen &lt;<a href=3D"mailto:vil=
le.voutilainen@gmail.com">ville.voutilainen@gmail.com</a>&gt; wrote:</div><=
br class=3D"Apple-interchange-newline"><blockquote type=3D"cite">On 10 July=
 2014 17:24, David Krauss &lt;<a href=3D"mailto:potswa@gmail.com">potswa@gm=
ail.com</a>&gt; wrote:<br><blockquote type=3D"cite">A return-by-reference f=
rom a non-ref-discriminated accessor devolving to<br>return-by-copy would r=
egress legacy code, but that doesn&rsquo;t make such library<br>behavior se=
mantically sound from a modern point of view.<br></blockquote><br>The "mode=
rn point of view" should include the forwarding concerns, which<br>are not =
limited to the performance of emplace.<br></blockquote><div><br></div><div>=
Absolutely. I&rsquo;m have an interest in this because I write this kind of=
 code.</div><br><blockquote type=3D"cite"><blockquote type=3D"cite">The rva=
lue-ref-qualified signatures need to return T&amp;&amp; instead of T.<br>LE=
WG needs an NB comment<br>to be able to make that fix for Fundamentals v1, =
and I'm going to provide<br>them<br>with one.<br><br><br>The rvalue-ref-qua=
lified signatures of what, std::optional? That&rsquo;s not a<br></blockquot=
e><br>Uh.. yes. That's the topic of this thread.<br></blockquote><div><br><=
/div></div>Maybe I don&rsquo;t understand the standardization process, but =
wouldn&rsquo;t the conservative solution be to simply roll that back from N=
4078, so optional behaves the same as everything else? Adding a new feature=
 in a particular way doesn&rsquo;t fall into the category of legacy support=
..<div><br></div><div>Optional is attempting to be the most perfect proxy cl=
ass ever designed, and it&rsquo;s pushing the envelope in a way that fundam=
entally disagrees with standardization. Simply put, it&rsquo;s churning too=
 much.</div><div><br></div><div>The debate can&rsquo;t be just about <font =
face=3D"Courier">optional</font>, even just in this thread, because the res=
t of the library is going to have to follow suit.</div><div><br></div></bod=
y></html>

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

--Apple-Mail=_36C7DCE8-AF9A-4998-B313-76D861386C7E--

.

------=_Part_303_17011130.1405005514834
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



W dniu czwartek, 10 lipca 2014 16:58:41 UTC+2 u=C5=BCytkownik David Krauss=
=20
napisa=C5=82:
>
>
> On 2014=E2=80=9307=E2=80=9310, at 10:44 PM, Ville Voutilainen <ville.vo..=
..@gmail.com=20
> <javascript:>> wrote:
>
> On 10 July 2014 17:24, David Krauss <pot...@gmail.com <javascript:>>=20
> wrote:
>
> A return-by-reference from a non-ref-discriminated accessor devolving to
> return-by-copy would regress legacy code, but that doesn=E2=80=99t make s=
uch=20
> library
> behavior semantically sound from a modern point of view.
>
>
> The "modern point of view" should include the forwarding concerns, which
> are not limited to the performance of emplace.
>
>
> Absolutely. I=E2=80=99m have an interest in this because I write this kin=
d of code.
>
> The rvalue-ref-qualified signatures need to return T&& instead of T.
> LEWG needs an NB comment
> to be able to make that fix for Fundamentals v1, and I'm going to provide
> them
> with one.
>
>
> The rvalue-ref-qualified signatures of what, std::optional? That=E2=80=99=
s not a
>
>
> Uh.. yes. That's the topic of this thread.
>
>
> Maybe I don=E2=80=99t understand the standardization process, but wouldn=
=E2=80=99t the=20
> conservative solution be to simply roll that back from N4078, so optional=
=20
> behaves the same as everything else? Adding a new feature in a particular=
=20
> way doesn=E2=80=99t fall into the category of legacy support.
>
> Optional is attempting to be the most perfect proxy class ever designed,=
=20
> and it=E2=80=99s pushing the envelope in a way that fundamentally disagre=
es with=20
> standardization. Simply put, it=E2=80=99s churning too much.
>
> The debate can=E2=80=99t be just about optional, even just in this thread=
,=20
> because the rest of the library is going to have to follow suit.
>

But having it in the optional<T> will create and existing practice will=20
make it easier to get the proposal that r-value overloads for other STL=20
container to get accepted. And maybe then we would have a full=20
implementation of this pattern in library. But without stepping stone like=
=20
optional it would be nearly impossible.

The history in short:
Firstly the following paper get published as part of 2014-05 mailing:=20
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3982.html. It adds=
=20
following overloads for the value and operator*:
  T& value() &;
  T const& value() const &;
  T&& value() &&;
And I really supported like that idea, because it makes the programmer life=
=20
easier. But then the https://isocpp.org/files/papers/N4078.html following=
=20
paper come out in 2014-07 mailing and it adds following overloads:
  T& value() &;
  T const& value() const &;
  T value() &&;
  T value() const &&;
And Anna started a thread raising an issues with this change. I hope that=
=20
clears up a think for you.
=20

--=20

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

------=_Part_303_17011130.1405005514834
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>W dniu czwartek, 10 lipca 2014 16:58:41 UTC+2 u=C5=
=BCytkownik David Krauss napisa=C5=82:<blockquote class=3D"gmail_quote" sty=
le=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left=
: 1ex;"><div style=3D"word-wrap:break-word"><br><div><div>On 2014=E2=80=930=
7=E2=80=9310, at 10:44 PM, Ville Voutilainen &lt;<a href=3D"javascript:" ta=
rget=3D"_blank" gdf-obfuscated-mailto=3D"1U-YOBR92nIJ" onmousedown=3D"this.=
href=3D'javascript:';return true;" onclick=3D"this.href=3D'javascript:';ret=
urn true;">ville.vo...@gmail.com</a>&gt; wrote:</div><br><blockquote type=
=3D"cite">On 10 July 2014 17:24, David Krauss &lt;<a href=3D"javascript:" t=
arget=3D"_blank" gdf-obfuscated-mailto=3D"1U-YOBR92nIJ" onmousedown=3D"this=
..href=3D'javascript:';return true;" onclick=3D"this.href=3D'javascript:';re=
turn true;">pot...@gmail.com</a>&gt; wrote:<br><blockquote type=3D"cite">A =
return-by-reference from a non-ref-discriminated accessor devolving to<br>r=
eturn-by-copy would regress legacy code, but that doesn=E2=80=99t make such=
 library<br>behavior semantically sound from a modern point of view.<br></b=
lockquote><br>The "modern point of view" should include the forwarding conc=
erns, which<br>are not limited to the performance of emplace.<br></blockquo=
te><div><br></div><div>Absolutely. I=E2=80=99m have an interest in this bec=
ause I write this kind of code.</div><br><blockquote type=3D"cite"><blockqu=
ote type=3D"cite">The rvalue-ref-qualified signatures need to return T&amp;=
&amp; instead of T.<br>LEWG needs an NB comment<br>to be able to make that =
fix for Fundamentals v1, and I'm going to provide<br>them<br>with one.<br><=
br><br>The rvalue-ref-qualified signatures of what, std::optional? That=E2=
=80=99s not a<br></blockquote><br>Uh.. yes. That's the topic of this thread=
..<br></blockquote><div><br></div></div>Maybe I don=E2=80=99t understand the=
 standardization process, but wouldn=E2=80=99t the conservative solution be=
 to simply roll that back from N4078, so optional behaves the same as every=
thing else? Adding a new feature in a particular way doesn=E2=80=99t fall i=
nto the category of legacy support.<div><br></div><div>Optional is attempti=
ng to be the most perfect proxy class ever designed, and it=E2=80=99s pushi=
ng the envelope in a way that fundamentally disagrees with standardization.=
 Simply put, it=E2=80=99s churning too much.</div><div><br></div><div>The d=
ebate can=E2=80=99t be just about <font face=3D"Courier">optional</font>, e=
ven just in this thread, because the rest of the library is going to have t=
o follow suit.</div></div></blockquote><div><br>But having it in the option=
al&lt;T&gt; will create and existing practice will make it easier to get th=
e proposal that r-value overloads for other STL container to get accepted. =
And maybe then we would have a full implementation of this pattern in libra=
ry. But without stepping stone like optional it would be nearly impossible.=
<br><br>The history in short:<br>Firstly the following paper get published =
as part of 2014-05 mailing: http://www.open-std.org/jtc1/sc22/wg21/docs/pap=
ers/2014/n3982.html. It adds following overloads for the value and operator=
*:<br>&nbsp;  T&amp; value() &amp;;<br>&nbsp; T const&amp; value() const &a=
mp;;<br>&nbsp; T&amp;&amp; value() &amp;&amp;;<br>And I really supported li=
ke that idea, because it makes the programmer life easier. But then the htt=
ps://isocpp.org/files/papers/N4078.html following paper come out in 2014-07=
 mailing and it adds following overloads:<br>&nbsp;  T&amp; value() &amp;;<=
br>&nbsp; T const&amp; value() const &amp;;<br>&nbsp; T value() &amp;&amp;;=
<br>&nbsp; T value() const &amp;&amp;;<br>And Anna started a thread raising=
 an issues with this change. I hope that clears up a think for you.<br></di=
v><div>&nbsp;</div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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_303_17011130.1405005514834--

.

On 10 July 2014 17:58, David Krauss <potswa@gmail.com> wrote:
>
> Maybe I don=E2=80=99t understand the standardization process, but wouldn=
=E2=80=99t the
> conservative solution be to simply roll that back from N4078, so optional
> behaves the same as everything else? Adding a new feature in a particular
> way doesn=E2=80=99t fall into the category of legacy support.

That's what everybody else but you have been suggesting in this thread -
make the signatures that were proposed to return T&& but changed to return =
T
return T&& again. o_O

>
> Optional is attempting to be the most perfect proxy class ever designed, =
and
> it=E2=80=99s pushing the envelope in a way that fundamentally disagrees w=
ith
> standardization. Simply put, it=E2=80=99s churning too much.

Mostly because people keep suggesting new churn that is in their opinion
massively important. This small rollback to the original design is not
"too much churn", it's a small fix at a suitable time, since optional is no=
where
near an actual standard. It's in a TS mostly for the reason that people hav=
e
wanted to keep tweaking it, but I expect that to calm down once the remaini=
ng
issues with the TS are resolved.

> The debate can=E2=80=99t be just about optional, even just in this thread=
, because
> the rest of the library is going to have to follow suit.


The rest of the library doesn't have to do anything. What a potential new
and incompatible library does is another matter.

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

.

--001a11c23e6c4894de04fddcaf7d
Content-Type: text/plain; charset=UTF-8

I may have missed it within the discussion, but has anyone suggested making
this version of the value() function =deleted?

Tony

--

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

--001a11c23e6c4894de04fddcaf7d
Content-Type: text/html; charset=UTF-8

<div dir="ltr"><div><br></div>I may have missed it within the discussion, but has anyone suggested making this version of the value() function =deleted?<br><div class="gmail_extra"><br></div><div class="gmail_extra">Tony<br>
</div><div class="gmail_extra"><br></div></div>

<p></p>

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

--001a11c23e6c4894de04fddcaf7d--

.

------=_Part_44_4648412.1405024477316
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

W dniu czwartek, 10 lipca 2014 22:29:43 UTC+2 u=C5=BCytkownik Tony V E napi=
sa=C5=82:
>
>
> I may have missed it within the discussion, but has anyone suggested=20
> making this version of the value() function =3Ddeleted?
>
> Tony
>
>
You would like the following code:
  std::optional<T> f();
  std::cout << f.value() << std::end;
To be ill-formed because of use of deleted method. May I ask why?

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

<div dir=3D"ltr">W dniu czwartek, 10 lipca 2014 22:29:43 UTC+2 u=C5=BCytkow=
nik Tony V E napisa=C5=82:<blockquote class=3D"gmail_quote" style=3D"margin=
: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div=
 dir=3D"ltr"><div><br></div>I may have missed it within the discussion, but=
 has anyone suggested making this version of the value() function =3Ddelete=
d?<br><div><br></div><div>Tony<br>
</div><div><br></div></div></blockquote><div><br>You would like the followi=
ng code:<br>&nbsp; std::optional&lt;T&gt; f();<br>&nbsp; std::cout &lt;&lt;=
 f.value() &lt;&lt; std::end;<br>To be ill-formed because of use of deleted=
 method. May I ask why?<br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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_44_4648412.1405024477316--

.

--001a11c3c3f879741904fddccee1
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Thu, Jul 10, 2014 at 4:34 PM, <tomaszkam@gmail.com> wrote:

> W dniu czwartek, 10 lipca 2014 22:29:43 UTC+2 u=C5=BCytkownik Tony V E na=
pisa=C5=82:
>
>>
>> I may have missed it within the discussion, but has anyone suggested
>> making this version of the value() function =3Ddeleted?
>>
>> Tony
>>
>>
> You would like the following code:
>   std::optional<T> f();
>   std::cout << f.value() << std::end;
> To be ill-formed because of use of deleted method. May I ask why?
>
>
>
Because there seemed to be discrepancies as to how it should work...


.... and because I didn't think it through very far :-)

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

--001a11c3c3f879741904fddccee1
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Thu, Jul 10, 2014 at 4:34 PM,  <span dir=3D"ltr">&lt;<a href=3D"=
mailto:tomaszkam@gmail.com" target=3D"_blank">tomaszkam@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">W dniu czwartek, 10 lipca 2=
014 22:29:43 UTC+2 u=C5=BCytkownik Tony V E napisa=C5=82:<div class=3D""><b=
lockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-=
left:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr"><div><br></div>I may have missed it within the discussion,=
 but has anyone suggested making this version of the value() function =3Dde=
leted?<br><div><br></div><div>Tony<br>
</div><div><br></div></div></blockquote></div><div><br>You would like the f=
ollowing code:<br>=C2=A0 std::optional&lt;T&gt; f();<br>=C2=A0 std::cout &l=
t;&lt; f.value() &lt;&lt; std::end;<br>To be ill-formed because of use of d=
eleted method. May I ask why?<br>
</div></div><div class=3D"HOEnZb"><div class=3D"h5">

<p></p><br></div></div></blockquote><div><br></div><div>Because there seeme=
d to be discrepancies as to how it should work...<br><br><br></div><div>...=
 and because I didn&#39;t think it through very far :-)<br><br>=C2=A0<br></=
div>
</div></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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 />

--001a11c3c3f879741904fddccee1--

.

On 2014-07-10, at 11:24 PM, Ville Voutilainen <ville.voutilainen@gmail.com> wrote:

> On 10 July 2014 17:58, David Krauss <potswa@gmail.com> wrote:
>>
>> Maybe I don't understand the standardization process, but wouldn't the
>> conservative solution be to simply roll that back from N4078, so optional
>> behaves the same as everything else? Adding a new feature in a particular
>> way doesn't fall into the category of legacy support.
>
> That's what everybody else but you have been suggesting in this thread -
> make the signatures that were proposed to return T&& but changed to return T
> return T&& again. o_O

What I meant is to return T const &, as in N3966, which precedes N4078. The changelog in N4078 is wrong... as I said, churn.

>> Optional is attempting to be the most perfect proxy class ever designed, and
>> it's pushing the envelope in a way that fundamentally disagrees with
>> standardization. Simply put, it's churning too much.
>
> Mostly because people keep suggesting new churn that is in their opinion
> massively important.

So it's their fault? The authors are the ones responsible for the proposal and its evolutionary path, post-adoption.

> This small rollback to the original design is not
> "too much churn",

Ohh, so the revision in between N3966 and N4078 is "the original design."

> The rest of the library doesn't have to do anything. What a potential new
> and incompatible library does is another matter.

Yeah right. The rest of the library can just arbitrarily decide to be incompatible.

It might be better to avoid arbitrariness in any part, and carefully think things through before a commitment is made on behalf of the whole C++ world, forever?

--

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

.

On 11 July 2014 01:01, David Krauss <potswa@gmail.com> wrote:
>> That's what everybody else but you have been suggesting in this thread -
>> make the signatures that were proposed to return T&& but changed to return T
>> return T&& again. o_O
> What I meant is to return T const &, as in N3966, which precedes N4078. The changelog in N4078 is wrong... as I said, churn.

T const &? So we could never move?

>>> Optional is attempting to be the most perfect proxy class ever designed, and
>>> it's pushing the envelope in a way that fundamentally disagrees with
>>> standardization. Simply put, it's churning too much.
>> Mostly because people keep suggesting new churn that is in their opinion
>> massively important.
> So it's their fault? The authors are the ones responsible for the proposal and its evolutionary path, post-adoption.

Yes, the authors can always just drop the whole proposal if they don't
like the modifications
the committee demands. Or they can try to cope with the modifications.

>> This small rollback to the original design is not
>> "too much churn",
> Ohh, so the revision in between N3966 and N4078 is "the original design."

The original design of the rvalue-ref-qualified overloads, sure.

>> The rest of the library doesn't have to do anything. What a potential new
>> and incompatible library does is another matter.
> Yeah right. The rest of the library can just arbitrarily decide to be incompatible.

Indeed it can.

> It might be better to avoid arbitrariness in any part, and carefully think things through before a commitment is made on behalf of the whole C++ world, forever?


Might be. I don't see what that's related to, so a "definitely
tentatively maybe".

--

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

.

--Apple-Mail=_57B4A170-AC9F-4C9D-83D4-7A7BE2B7FBBF
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1


On 2014-07-11, at 6:19 AM, Ville Voutilainen <ville.voutilainen@gmail.com> =
wrote:

> On 11 July 2014 01:01, David Krauss <potswa@gmail.com> wrote:
>> What I meant is to return T const &, as in N3966, which precedes N4078. =
The changelog in N4078 is wrong... as I said, churn.
>=20
> T const &? So we could never move?

Sorry, first thing in the morning. Roll back to N3966, the preceding regist=
ered-paper revision. It has two value() overloads, just like container and =
smart pointer accessors.

> Yes, the authors can always just drop the whole proposal if they don't
> like the modifications
> the committee demands. Or they can try to cope with the modifications.

Did you try suggesting to save the modification for later, that more experi=
ence would be useful?

> The original design of the rvalue-ref-qualified overloads, sure.

That's not how software features work. A reasonable definition for "the ori=
ginal design" would be boost::optional, which is in popular use. (It's unfo=
rtunate that Boost is not helping to prototype TS1, I guess it's ironically=
 become too resistant to change.)

>> Yeah right. The rest of the library can just arbitrarily decide to be in=
compatible.
>=20
> Indeed it can.

Quoting the other guy in this debate:

> But having it in the optional<T> will create and existing practice will m=
ake it easier to get the proposal that r-value overloads for other STL cont=
ainer to get accepted. And maybe then we would have a full implementation o=
f this pattern in library. But without stepping stone like optional it woul=
d be nearly impossible.

In American football (and politics), this is called an "end run."

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

--Apple-Mail=_57B4A170-AC9F-4C9D-83D4-7A7BE2B7FBBF
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014&=
ndash;07&ndash;11, at 6:19 AM, Ville Voutilainen &lt;<a href=3D"mailto:vill=
e.voutilainen@gmail.com">ville.voutilainen@gmail.com</a>&gt; wrote:</div><b=
r class=3D"Apple-interchange-newline"><blockquote type=3D"cite">On 11 July =
2014 01:01, David Krauss &lt;<a href=3D"mailto:potswa@gmail.com">potswa@gma=
il.com</a>&gt; wrote:<br><blockquote type=3D"cite">What I meant is to retur=
n T const &amp;, as in N3966, which precedes N4078. The changelog in N4078 =
is wrong... as I said, churn.<br></blockquote><br>T const &amp;? So we coul=
d never move?<br></blockquote><div><br></div><div>Sorry, first thing in the=
 morning. Roll back to N3966, the preceding registered-paper revision. It h=
as two value() overloads, just like container and smart pointer accessors.<=
/div><br><blockquote type=3D"cite">Yes, the authors can always just drop th=
e whole proposal if they don't<br>like the modifications<br>the committee d=
emands. Or they can try to cope with the modifications.<br></blockquote><di=
v><br></div><div>Did you try suggesting to save the modification for later,=
 that more experience would be useful?</div><br><blockquote type=3D"cite">T=
he original design of the rvalue-ref-qualified overloads, sure.</blockquote=
><div><br></div><div>That&rsquo;s not how software features work. A reasona=
ble definition for &ldquo;the original design&rdquo; would be <font face=3D=
"Courier">boost::optional</font>, which is in popular use. (It&rsquo;s unfo=
rtunate that Boost is not helping to prototype TS1, I guess it&rsquo;s iron=
ically become too resistant to change.)</div><br><blockquote type=3D"cite">=
<blockquote type=3D"cite">Yeah right. The rest of the library can just arbi=
trarily decide to be incompatible.<br></blockquote><br>Indeed it can.<br></=
blockquote><div><br></div><div>Quoting the other guy in this debate:</div><=
div><br></div><div><blockquote type=3D"cite">But having it in the optional&=
lt;T&gt; will create and existing practice will make it easier to get the p=
roposal that r-value&nbsp;overloads for other STL container to get accepted=
.. And maybe then we would have a full implementation of this&nbsp;pattern i=
n library. But without stepping stone like optional it would be nearly impo=
ssible.</blockquote><br></div><div>In American football (and politics), thi=
s is called an &ldquo;end run.&rdquo;</div></div><br></body></html>

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

--Apple-Mail=_57B4A170-AC9F-4C9D-83D4-7A7BE2B7FBBF--

.

------=_Part_187_7527615.1405056517307
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



W dniu pi=C4=85tek, 11 lipca 2014 00:59:12 UTC+2 u=C5=BCytkownik David Krau=
ss napisa=C5=82:
>
>
> On 2014=E2=80=9307=E2=80=9311, at 6:19 AM, Ville Voutilainen <ville.vo...=
@gmail.com=20
> <javascript:>> wrote:
>
> On 11 July 2014 01:01, David Krauss <pot...@gmail.com <javascript:>>=20
> wrote:
>
> What I meant is to return T const &, as in N3966, which precedes N4078.=
=20
> The changelog in N4078 is wrong... as I said, churn.
>
>
> T const &? So we could never move?
>
>
> Sorry, first thing in the morning. Roll back to N3966, the preceding=20
> registered-paper revision. It has two value() overloads, just like=20
> container and smart pointer accessors.
>
>
But I would like to ask for argument for removal of this additional=20
overload.=20


 I we add the following r-value overload as originally proposed, it will=20
have following effect: //as always: optional<T> f();
  1. *std::forward<U>(u) with optional will actually perfectly forward=20
  2. auto&& v =3D f().value() - will still create a dangling refence (as it=
=20
it will now we two dangling reference), auto will be deduced to T instead=
=20
of T&, but v still we be l-value
  3. g(f.value()), when g(const T&) accepts by cont& will work the same
  4. h(f.value()), when h(T) accepts by value, will benefit from move
  5. f().value() =3D 20, will no longer compile if T has l-value qualified=
=20
operator=3D(T const&) & //this actullay should be a true
I found this actually being good not-breaking changes, similar to one=20
created my adding move constructor to every feasible class in C++11.=20
And even adding it to the single optional will not create any surprising=20
effect in the code
I think adding such overloads to containers is actually possible, without=
=20
breaking many code.

Coud you please provide arguments, best corner cases, that makes you being=
=20
against this change. I think they may get lost in this discussion because=
=20
we are thinking that you are=20
recommending to have T value()&& instead of T&& value()&&, not removing it=
=20
at all.

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

<div dir=3D"ltr"><br><br>W dniu pi=C4=85tek, 11 lipca 2014 00:59:12 UTC+2 u=
=C5=BCytkownik David Krauss napisa=C5=82:<blockquote class=3D"gmail_quote" =
style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-l=
eft: 1ex;"><div style=3D"word-wrap:break-word"><br><div><div>On 2014=E2=80=
=9307=E2=80=9311, at 6:19 AM, Ville Voutilainen &lt;<a href=3D"javascript:"=
 target=3D"_blank" gdf-obfuscated-mailto=3D"ajbvGTK5VdUJ" onmousedown=3D"th=
is.href=3D'javascript:';return true;" onclick=3D"this.href=3D'javascript:';=
return true;">ville.vo...@gmail.com</a>&gt; wrote:</div><br><blockquote typ=
e=3D"cite">On 11 July 2014 01:01, David Krauss &lt;<a href=3D"javascript:" =
target=3D"_blank" gdf-obfuscated-mailto=3D"ajbvGTK5VdUJ" onmousedown=3D"thi=
s.href=3D'javascript:';return true;" onclick=3D"this.href=3D'javascript:';r=
eturn true;">pot...@gmail.com</a>&gt; wrote:<br><blockquote type=3D"cite">W=
hat I meant is to return T const &amp;, as in N3966, which precedes N4078. =
The changelog in N4078 is wrong... as I said, churn.<br></blockquote><br>T =
const &amp;? So we could never move?<br></blockquote><div><br></div><div>So=
rry, first thing in the morning. Roll back to N3966, the preceding register=
ed-paper revision. It has two value() overloads, just like container and sm=
art pointer accessors.</div><br></div></div></blockquote><div><br>But I wou=
ld like to ask for argument for removal of this additional overload. <br><b=
r><br>&nbsp;I we add the following r-value overload as originally proposed,=
 it will have following effect: //as always: optional&lt;T&gt; f();<br>&nbs=
p; 1. *std::forward&lt;U&gt;(u) with optional will actually perfectly forwa=
rd <br>&nbsp; 2. auto&amp;&amp; v =3D f().value() - will still create a dan=
gling refence (as it it will now we two dangling reference), auto will be d=
educed to T instead of T&amp;, but v still we be l-value<br>&nbsp; 3. g(f.v=
alue()), when g(const T&amp;) accepts by cont&amp; will work the same<br>&n=
bsp; 4. h(f.value()), when h(T) accepts by value, will benefit from move<br=
>&nbsp; 5. f().value() =3D 20, will no longer compile if T has l-value qual=
ified operator=3D(T const&amp;) &amp; //this actullay should be a true<br>I=
 found this actually being good not-breaking changes, similar to one create=
d my adding move constructor to every feasible class in C++11. <br>And even=
 adding it to the single optional will not create any surprising effect in =
the code<br>I think adding such overloads to containers is actually possibl=
e, without breaking many code.<br><br>Coud you please provide arguments, be=
st corner cases, that makes you being against this change. I think they may=
 get lost in this discussion because we are thinking that you are <br>recom=
mending to have T value()&amp;&amp; instead of T&amp;&amp; value()&amp;&amp=
;, not removing it at all.<br><br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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_187_7527615.1405056517307--

.

On 11 July 2014 08:28,  <tomaszkam@gmail.com> wrote:
>  I we add the following r-value overload as originally proposed, it will
> have following effect: //as always: optional<T> f();
>   1. *std::forward<U>(u) with optional will actually perfectly forward
>   2. auto&& v = f().value() - will still create a dangling refence (as it it
> will now we two dangling reference), auto will be deduced to T instead of
> T&, but v still we be l-value
>   3. g(f.value()), when g(const T&) accepts by cont& will work the same
>   4. h(f.value()), when h(T) accepts by value, will benefit from move
>   5. f().value() = 20, will no longer compile if T has l-value qualified
> operator=(T const&) & //this actullay should be a true
> I found this actually being good not-breaking changes, similar to one
> created my adding move constructor to every feasible class in C++11.
> And even adding it to the single optional will not create any surprising
> effect in the code
> I think adding such overloads to containers is actually possible, without
> breaking many code.


I think we should do what N3982 does with the addition of
const-rvalue-ref-qualified
 overloads. With the addition of those, people who care about
forwarding const-rvalues
perfectly will get what they need.

--

---
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_45_25740.1405064416755
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


W dniu pi=C4=85tek, 11 lipca 2014 00:59:12 UTC+2 u=C5=BCytkownik David Krau=
ss napisa=C5=82:
>
>
> On 2014=E2=80=9307=E2=80=9311, at 6:19 AM, Ville Voutilainen <ville.vo...=
@gmail.com=20
> <javascript:>> wrote:
>
> On 11 July 2014 01:01, David Krauss <pot...@gmail.com <javascript:>>=20
> wrote:
>
> What I meant is to return T const &, as in N3966, which precedes N4078.=
=20
> The changelog in N4078 is wrong... as I said, churn.
>
>
> T const &? So we could never move?
>
>
> Sorry, first thing in the morning. Roll back to N3966, the preceding=20
> registered-paper revision. It has two value() overloads, just like=20
> container and smart pointer accessors.
>
> Yes, the authors can always just drop the whole proposal if they don't
> like the modifications
> the committee demands. Or they can try to cope with the modifications.
>
>
> Did you try suggesting to save the modification for later, that more=20
> experience would be useful?
>
> The original design of the rvalue-ref-qualified overloads, sure.
>
>
> That=E2=80=99s not how software features work. A reasonable definition fo=
r =E2=80=9Cthe=20
> original design=E2=80=9D would be boost::optional, which is in popular us=
e. (It=E2=80=99s=20
> unfortunate that Boost is not helping to prototype TS1, I guess it=E2=80=
=99s=20
> ironically become too resistant to change.)
>
=20


W dniu pi=C4=85tek, 11 lipca 2014 00:59:12 UTC+2 u=C5=BCytkownik David Krau=
ss napisa=C5=82:
>
>
> On 2014=E2=80=9307=E2=80=9311, at 6:19 AM, Ville Voutilainen <*ville.vo..=
..@gmail.com*=20
> <javascript:>> wrote:
>
> On 11 July 2014 01:01, David Krauss <*pot...@gmail.com* <javascript:>>=20
> wrote:
>
> What I meant is to return T const &, as in N3966, which precedes N4078.=
=20
> The changelog in N4078 is wrong... as I said, churn.
>
>
> T const &? So we could never move?
>
>
> Sorry, first thing in the morning. Roll back to N3966, the preceding=20
> registered-paper revision. It has two value() overloads, just like=20
> container and smart pointer accessors.
>

Guys, I just want to summarize what is being discussed here so that=20
everyone is on the same page. We are discussing how overloads operator*()=
=20
and value() are defined in optional.

Prior to the adoption of *N4078*=20
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4078.html>, the=
=20
Fundamentals TS had them as:
T& operator*();
T const& operator*() const;

T& value();
T const& value() const;

With the adoption of *N4078*=20
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4078.html>,=20
Fundamentals TS has:
T& operator*() &;
T const& operator*() const&;
T operator*() &&;            // by value
T operator*() const&&;       // by value

T& value() &;
T const& value() const&;
T value() &&;                // by value
T value() const&&;           // by value

Now the change that Anna and Tomasz and Ville are considering (an I=20
support) is for Fundamentals TS to have:
T& operator*() &;
T const& operator*() const&;
T&& operator*() &&;          // by rvalue ref

T& value() &;
T const& value() const&;
T&& value() &&;                // by rvalue ref

So we are not reverting the change. We change further.

Am I right?
&rzej
=20

--=20

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

------=_Part_45_25740.1405064416755
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br>W dniu pi=C4=85tek, 11 lipca 2014 00:59:12 UTC+2 u=C5=
=BCytkownik David Krauss napisa=C5=82:<blockquote style=3D"margin: 0px 0px =
0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border=
-left-width: 1px; border-left-style: solid;" class=3D"gmail_quote"><div sty=
le=3D"word-wrap: break-word;"><br><div><div>On 2014=E2=80=9307=E2=80=9311, =
at 6:19 AM, Ville Voutilainen &lt;<a onmousedown=3D"this.href=3D'javascript=
:';return true;" onclick=3D"this.href=3D'javascript:';return true;" href=3D=
"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"ajbvGTK5VdUJ">vill=
e.vo...@gmail.com</a>&gt; wrote:</div><br><blockquote type=3D"cite">On 11 J=
uly 2014 01:01, David Krauss &lt;<a onmousedown=3D"this.href=3D'javascript:=
';return true;" onclick=3D"this.href=3D'javascript:';return true;" href=3D"=
javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"ajbvGTK5VdUJ">pot..=
..@gmail.com</a>&gt; wrote:<br><blockquote type=3D"cite">What I meant is to =
return T const &amp;, as in N3966, which precedes N4078. The changelog in N=
4078 is wrong... as I said, churn.<br></blockquote><br>T const &amp;? So we=
 could never move?<br></blockquote><div><br></div><div>Sorry, first thing i=
n the morning. Roll back to N3966, the preceding registered-paper revision.=
 It has two value() overloads, just like container and smart pointer access=
ors.</div><br><blockquote type=3D"cite">Yes, the authors can always just dr=
op the whole proposal if they don't<br>like the modifications<br>the commit=
tee demands. Or they can try to cope with the modifications.<br></blockquot=
e><div><br></div><div>Did you try suggesting to save the modification for l=
ater, that more experience would be useful?</div><br><blockquote type=3D"ci=
te">The original design of the rvalue-ref-qualified overloads, sure.</block=
quote><div><br></div><div>That=E2=80=99s not how software features work. A =
reasonable definition for =E2=80=9Cthe original design=E2=80=9D would be <f=
ont face=3D"Courier">boost::optional</font>, which is in popular use. (It=
=E2=80=99s unfortunate that Boost is not helping to prototype TS1, I guess =
it=E2=80=99s ironically become too resistant to change.)</div></div></div><=
/blockquote><div>&nbsp;</div><div><br><br>W dniu pi=C4=85tek, 11 lipca 2014=
 00:59:12 UTC+2 u=C5=BCytkownik David Krauss napisa=C5=82:<blockquote style=
=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(20=
4, 204, 204); border-left-width: 1px; border-left-style: solid;" class=3D"g=
mail_quote"><div style=3D"word-wrap: break-word;"><br><div><div>On 2014=E2=
=80=9307=E2=80=9311, at 6:19 AM, Ville Voutilainen &lt;<a onmousedown=3D"th=
is.href=3D'javascript:';return true;" onclick=3D"this.href=3D'javascript:';=
return true;" href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=
=3D"ajbvGTK5VdUJ"><u><font color=3D"#0066cc">ville.vo...@gmail.com</font></=
u></a>&gt; wrote:</div><br><blockquote type=3D"cite">On 11 July 2014 01:01,=
 David Krauss &lt;<a onmousedown=3D"this.href=3D'javascript:';return true;"=
 onclick=3D"this.href=3D'javascript:';return true;" href=3D"javascript:" ta=
rget=3D"_blank" gdf-obfuscated-mailto=3D"ajbvGTK5VdUJ"><u><font color=3D"#0=
066cc">pot...@gmail.com</font></u></a>&gt; wrote:<br><blockquote type=3D"ci=
te">What I meant is to return T const &amp;, as in N3966, which precedes N4=
078. The changelog in N4078 is wrong... as I said, churn.<br></blockquote><=
br>T const &amp;? So we could never move?<br></blockquote><div><br></div><d=
iv>Sorry,
 first thing in the morning. Roll back to N3966, the preceding=20
registered-paper revision. It has two value() overloads, just like=20
container and smart pointer accessors.</div></div></div></blockquote><div><=
br>Guys,
 I just want to summarize what is being discussed here so that everyone=20
is on the same page. We are discussing how overloads operator*() and=20
value() are defined in optional.<br><br>Prior to the adoption of <a href=3D=
"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4078.html"><u><fo=
nt color=3D"#0066cc">N4078</font></u></a>, the Fundamentals TS had them as:=
<br><div style=3D"border: 1px solid rgb(187, 187, 187); word-wrap: break-wo=
rd; background-color: rgb(250, 250, 250);" class=3D"prettyprint"><code clas=
s=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: rgb(0=
, 0, 0);" class=3D"styled-by-prettify">T</span><span style=3D"color: rgb(10=
2, 102, 0);" class=3D"styled-by-prettify">&amp;</span><span style=3D"color:=
 rgb(0, 0, 0);" class=3D"styled-by-prettify"> </span><span style=3D"color: =
rgb(0, 0, 136);" class=3D"styled-by-prettify">operator</span><span style=3D=
"color: rgb(102, 102, 0);" class=3D"styled-by-prettify">*();</span><span st=
yle=3D"color: rgb(0, 0, 0);" class=3D"styled-by-prettify"><br>T </span><spa=
n style=3D"color: rgb(0, 0, 136);" class=3D"styled-by-prettify">const</span=
><span style=3D"color: rgb(102, 102, 0);" class=3D"styled-by-prettify">&amp=
;</span><span style=3D"color: rgb(0, 0, 0);" class=3D"styled-by-prettify"> =
</span><span style=3D"color: rgb(0, 0, 136);" class=3D"styled-by-prettify">=
operator</span><span style=3D"color: rgb(102, 102, 0);" class=3D"styled-by-=
prettify">*()</span><span style=3D"color: rgb(0, 0, 0);" class=3D"styled-by=
-prettify"> </span><span style=3D"color: rgb(0, 0, 136);" class=3D"styled-b=
y-prettify">const</span><span style=3D"color: rgb(102, 102, 0);" class=3D"s=
tyled-by-prettify">;</span><span style=3D"color: rgb(0, 0, 0);" class=3D"st=
yled-by-prettify"><br><br>T</span><span style=3D"color: rgb(102, 102, 0);" =
class=3D"styled-by-prettify">&amp;</span><span style=3D"color: rgb(0, 0, 0)=
;" class=3D"styled-by-prettify"> value</span><span style=3D"color: rgb(102,=
 102, 0);" class=3D"styled-by-prettify">();</span><span style=3D"color: rgb=
(0, 0, 0);" class=3D"styled-by-prettify"><br>T </span><span style=3D"color:=
 rgb(0, 0, 136);" class=3D"styled-by-prettify">const</span><span style=3D"c=
olor: rgb(102, 102, 0);" class=3D"styled-by-prettify">&amp;</span><span sty=
le=3D"color: rgb(0, 0, 0);" class=3D"styled-by-prettify"> value</span><span=
 style=3D"color: rgb(102, 102, 0);" class=3D"styled-by-prettify">()</span><=
span style=3D"color: rgb(0, 0, 0);" class=3D"styled-by-prettify"> </span><s=
pan style=3D"color: rgb(0, 0, 136);" class=3D"styled-by-prettify">const</sp=
an><span style=3D"color: rgb(102, 102, 0);" class=3D"styled-by-prettify">;<=
/span><span style=3D"color: rgb(0, 0, 0);" class=3D"styled-by-prettify"><br=
></span></div></code></div><br>With the adoption of <a href=3D"http://www.o=
pen-std.org/jtc1/sc22/wg21/docs/papers/2014/n4078.html"><u><font color=3D"#=
0066cc">N4078</font></u></a>, Fundamentals TS has:<br><div style=3D"border:=
 1px solid rgb(187, 187, 187); word-wrap: break-word; background-color: rgb=
(250, 250, 250);" class=3D"prettyprint"><code class=3D"prettyprint"><div cl=
ass=3D"subprettyprint"><span style=3D"color: rgb(0, 0, 0);" class=3D"styled=
-by-prettify">T</span><span style=3D"color: rgb(102, 102, 0);" class=3D"sty=
led-by-prettify">&amp;</span><span style=3D"color: rgb(0, 0, 0);" class=3D"=
styled-by-prettify"> </span><span style=3D"color: rgb(0, 0, 136);" class=3D=
"styled-by-prettify">operator</span><span style=3D"color: rgb(102, 102, 0);=
" class=3D"styled-by-prettify">*()</span><span style=3D"color: rgb(0, 0, 0)=
;" class=3D"styled-by-prettify"> </span><span style=3D"color: rgb(102, 102,=
 0);" class=3D"styled-by-prettify">&amp;;</span><span style=3D"color: rgb(0=
, 0, 0);" class=3D"styled-by-prettify"><br>T </span><span style=3D"color: r=
gb(0, 0, 136);" class=3D"styled-by-prettify">const</span><span style=3D"col=
or: rgb(102, 102, 0);" class=3D"styled-by-prettify">&amp;</span><span style=
=3D"color: rgb(0, 0, 0);" class=3D"styled-by-prettify"> </span><span style=
=3D"color: rgb(0, 0, 136);" class=3D"styled-by-prettify">operator</span><sp=
an style=3D"color: rgb(102, 102, 0);" class=3D"styled-by-prettify">*()</spa=
n><span style=3D"color: rgb(0, 0, 0);" class=3D"styled-by-prettify"> </span=
><span style=3D"color: rgb(0, 0, 136);" class=3D"styled-by-prettify">const<=
/span><span style=3D"color: rgb(102, 102, 0);" class=3D"styled-by-prettify"=
>&amp;;</span><span style=3D"color: rgb(0, 0, 0);" class=3D"styled-by-prett=
ify"><br>T </span><span style=3D"color: rgb(0, 0, 136);" class=3D"styled-by=
-prettify">operator</span><span style=3D"color: rgb(102, 102, 0);" class=3D=
"styled-by-prettify">*()</span><span style=3D"color: rgb(0, 0, 0);" class=
=3D"styled-by-prettify"> </span><span style=3D"color: rgb(102, 102, 0);" cl=
ass=3D"styled-by-prettify">&amp;&amp;;</span><span style=3D"color: rgb(0, 0=
, 0);" class=3D"styled-by-prettify"></span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; // by value<br><span style=3D"color: rgb=
(0, 0, 0);" class=3D"styled-by-prettify"><code class=3D"prettyprint"><span =
style=3D"color: rgb(0, 0, 0);" class=3D"styled-by-prettify">T </span><span =
style=3D"color: rgb(0, 0, 136);" class=3D"styled-by-prettify">operator</spa=
n><span style=3D"color: rgb(102, 102, 0);" class=3D"styled-by-prettify">*()=
</span><span style=3D"color: rgb(0, 0, 0);" class=3D"styled-by-prettify"> c=
onst</span><span style=3D"color: rgb(102, 102, 0);" class=3D"styled-by-pret=
tify">&amp;&amp;;</span><span style=3D"color: rgb(0, 0, 0);" class=3D"style=
d-by-prettify">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; // by value<br></span><=
/code><br>T</span><span style=3D"color: rgb(102, 102, 0);" class=3D"styled-=
by-prettify">&amp;</span><span style=3D"color: rgb(0, 0, 0);" class=3D"styl=
ed-by-prettify"> value</span><span style=3D"color: rgb(102, 102, 0);" class=
=3D"styled-by-prettify">() &amp;;</span><span style=3D"color: rgb(0, 0, 0);=
" class=3D"styled-by-prettify"><br>T </span><span style=3D"color: rgb(0, 0,=
 136);" class=3D"styled-by-prettify">const</span><span style=3D"color: rgb(=
102, 102, 0);" class=3D"styled-by-prettify">&amp;</span><span style=3D"colo=
r: rgb(0, 0, 0);" class=3D"styled-by-prettify"> value</span><span style=3D"=
color: rgb(102, 102, 0);" class=3D"styled-by-prettify">()</span><span style=
=3D"color: rgb(0, 0, 0);" class=3D"styled-by-prettify"> </span><span style=
=3D"color: rgb(0, 0, 136);" class=3D"styled-by-prettify">const&amp;</span><=
span style=3D"color: rgb(102, 102, 0);" class=3D"styled-by-prettify">;</spa=
n><span style=3D"color: rgb(0, 0, 0);" class=3D"styled-by-prettify"></span>=
<br><code class=3D"prettyprint"><span style=3D"color: rgb(0, 0, 0);" class=
=3D"styled-by-prettify">T</span><span style=3D"color: rgb(102, 102, 0);" cl=
ass=3D"styled-by-prettify"></span><span style=3D"color: rgb(0, 0, 0);" clas=
s=3D"styled-by-prettify"> value</span><span style=3D"color: rgb(102, 102, 0=
);" class=3D"styled-by-prettify">() &amp;&amp;;</span><span style=3D"color:=
 rgb(0, 0, 0);" class=3D"styled-by-prettify">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; // by value<br=
>T</span><span style=3D"color: rgb(0, 0, 0);" class=3D"styled-by-prettify">=
 value</span><span style=3D"color: rgb(102, 102, 0);" class=3D"styled-by-pr=
ettify">()</span><span style=3D"color: rgb(0, 0, 0);" class=3D"styled-by-pr=
ettify"> </span><span style=3D"color: rgb(0, 0, 136);" class=3D"styled-by-p=
rettify">const</span><span style=3D"color: rgb(102, 102, 0);" class=3D"styl=
ed-by-prettify">&amp;&amp;;</span><span style=3D"color: rgb(0, 0, 0);" clas=
s=3D"styled-by-prettify">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp; // by value<br></span></code></div></code></div><br>Now the chan=
ge that Anna and Tomasz and Ville are considering (an I support) is for Fun=
damentals TS to have:<br><div style=3D"border: 1px solid rgb(187, 187, 187)=
; word-wrap: break-word; background-color: rgb(250, 250, 250);" class=3D"pr=
ettyprint"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span =
style=3D"color: rgb(0, 0, 0);" class=3D"styled-by-prettify">T</span><span s=
tyle=3D"color: rgb(102, 102, 0);" class=3D"styled-by-prettify">&amp;</span>=
<span style=3D"color: rgb(0, 0, 0);" class=3D"styled-by-prettify"> </span><=
span style=3D"color: rgb(0, 0, 136);" class=3D"styled-by-prettify">operator=
</span><span style=3D"color: rgb(102, 102, 0);" class=3D"styled-by-prettify=
">*()</span><span style=3D"color: rgb(0, 0, 0);" class=3D"styled-by-prettif=
y"> </span><span style=3D"color: rgb(102, 102, 0);" class=3D"styled-by-pret=
tify">&amp;;</span><span style=3D"color: rgb(0, 0, 0);" class=3D"styled-by-=
prettify"><br>T </span><span style=3D"color: rgb(0, 0, 136);" class=3D"styl=
ed-by-prettify">const</span><span style=3D"color: rgb(102, 102, 0);" class=
=3D"styled-by-prettify">&amp;</span><span style=3D"color: rgb(0, 0, 0);" cl=
ass=3D"styled-by-prettify"> </span><span style=3D"color: rgb(0, 0, 136);" c=
lass=3D"styled-by-prettify">operator</span><span style=3D"color: rgb(102, 1=
02, 0);" class=3D"styled-by-prettify">*()</span><span style=3D"color: rgb(0=
, 0, 0);" class=3D"styled-by-prettify"> </span><span style=3D"color: rgb(0,=
 0, 136);" class=3D"styled-by-prettify">const</span><span style=3D"color: r=
gb(102, 102, 0);" class=3D"styled-by-prettify">&amp;;</span><span style=3D"=
color: rgb(0, 0, 0);" class=3D"styled-by-prettify"><br>T&amp;&amp; </span><=
span style=3D"color: rgb(0, 0, 136);" class=3D"styled-by-prettify">operator=
</span><span style=3D"color: rgb(102, 102, 0);" class=3D"styled-by-prettify=
">*()</span><span style=3D"color: rgb(0, 0, 0);" class=3D"styled-by-prettif=
y"> </span><span style=3D"color: rgb(102, 102, 0);" class=3D"styled-by-pret=
tify">&amp;&amp;;</span><span style=3D"color: rgb(0, 0, 0);" class=3D"style=
d-by-prettify"> &nbsp; &nbsp; &nbsp;&nbsp;&nbsp;&nbsp; </span><span style=
=3D"color: rgb(136, 0, 0);" class=3D"styled-by-prettify">// by rvalue ref</=
span><span style=3D"color: rgb(0, 0, 0);" class=3D"styled-by-prettify"></sp=
an><span style=3D"color: rgb(0, 0, 0);" class=3D"styled-by-prettify"><br><b=
r>T</span><span style=3D"color: rgb(102, 102, 0);" class=3D"styled-by-prett=
ify">&amp;</span><span style=3D"color: rgb(0, 0, 0);" class=3D"styled-by-pr=
ettify"> value</span><span style=3D"color: rgb(102, 102, 0);" class=3D"styl=
ed-by-prettify">()</span><span style=3D"color: rgb(0, 0, 0);" class=3D"styl=
ed-by-prettify"> </span><span style=3D"color: rgb(102, 102, 0);" class=3D"s=
tyled-by-prettify">&amp;;</span><span style=3D"color: rgb(0, 0, 0);" class=
=3D"styled-by-prettify"><br>T </span><span style=3D"color: rgb(0, 0, 136);"=
 class=3D"styled-by-prettify">const</span><span style=3D"color: rgb(102, 10=
2, 0);" class=3D"styled-by-prettify">&amp;</span><span style=3D"color: rgb(=
0, 0, 0);" class=3D"styled-by-prettify"> value</span><span style=3D"color: =
rgb(102, 102, 0);" class=3D"styled-by-prettify">()</span><span style=3D"col=
or: rgb(0, 0, 0);" class=3D"styled-by-prettify"> </span><span style=3D"colo=
r: rgb(0, 0, 136);" class=3D"styled-by-prettify">const</span><span style=3D=
"color: rgb(102, 102, 0);" class=3D"styled-by-prettify">&amp;;</span><span =
style=3D"color: rgb(0, 0, 0);" class=3D"styled-by-prettify"><br>T&amp;&amp;=
 value</span><span style=3D"color: rgb(102, 102, 0);" class=3D"styled-by-pr=
ettify">()</span><span style=3D"color: rgb(0, 0, 0);" class=3D"styled-by-pr=
ettify"> </span><span style=3D"color: rgb(102, 102, 0);" class=3D"styled-by=
-prettify">&amp;&amp;;</span><span style=3D"color: rgb(0, 0, 0);" class=3D"=
styled-by-prettify"> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp=
;</span><span style=3D"color: rgb(136, 0, 0);" class=3D"styled-by-prettify"=
>// by rvalue</span><span style=3D"color: rgb(0, 0, 0);" class=3D"styled-by=
-prettify"> ref</span><span style=3D"color: rgb(0, 0, 0);" class=3D"styled-=
by-prettify"><br></span></div></code></div><br>So we are not reverting the =
change. We change further.<br><br>Am I right?<br>&amp;rzej<br></div>&nbsp;<=
/div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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_45_25740.1405064416755--

.

--047d7b5da0937fec0104fde62f14
Content-Type: text/plain; charset=UTF-8

You mean that:
  T const&& value() const&&;
I see no additional problem with adding that. Not uses case come to my mind
at this moment, but I am pretty sure that someone will found one.

 I thin we should think of some kind of defininig template for this
specializations
 U _member;

 I would propose:
 template<this T> //real type of object (example T const& for cons& funtion
 delctype(auto) member() { return std::forward<same_cv_as<T, U>>(_member);
}; //cv ref deduced\

 template<this T> //real type of object
 delctype(auto) member()  const { return std::forward<same_cv_as<T,
U>>(_member); }; //ref deduced, const specified

 template<this T> //real type of object
 delctype(auto) member()  & { return std::forward<same_cv_as<T,
U>>(_member); }; //cv deduced, ref specified

 template<this T> //real type of object
 delctype(auto) member()  cont & { return std::forward<same_cv_as<T,
U>>(_member); }; //eror, not think to dedupe


2014-07-11 9:35 GMT+02:00 Ville Voutilainen <ville.voutilainen@gmail.com>:

> On 11 July 2014 08:28,  <tomaszkam@gmail.com> wrote:
> >  I we add the following r-value overload as originally proposed, it will
> > have following effect: //as always: optional<T> f();
> >   1. *std::forward<U>(u) with optional will actually perfectly forward
> >   2. auto&& v = f().value() - will still create a dangling refence (as
> it it
> > will now we two dangling reference), auto will be deduced to T instead of
> > T&, but v still we be l-value
> >   3. g(f.value()), when g(const T&) accepts by cont& will work the same
> >   4. h(f.value()), when h(T) accepts by value, will benefit from move
> >   5. f().value() = 20, will no longer compile if T has l-value qualified
> > operator=(T const&) & //this actullay should be a true
> > I found this actually being good not-breaking changes, similar to one
> > created my adding move constructor to every feasible class in C++11.
> > And even adding it to the single optional will not create any surprising
> > effect in the code
> > I think adding such overloads to containers is actually possible, without
> > breaking many code.
>
>
> I think we should do what N3982 does with the addition of
> const-rvalue-ref-qualified
>  overloads. With the addition of those, people who care about
> forwarding const-rvalues
> perfectly will get what they need.
>
> --
>
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/jDRQyBWYl8Q/unsubscribe
> .
> To unsubscribe from this group and all its topics, send an email to
> std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--

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

--047d7b5da0937fec0104fde62f14
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div><div><div>You mean that:<br></div>=C2=A0 T const=
&amp;&amp; value() const&amp;&amp;;<br></div>I see no additional problem wi=
th adding that. Not uses case come to my mind at this moment, but I am pret=
ty sure that someone will found one.<br>
<br>=C2=A0I thin we should think of some kind of defininig template for thi=
s specializations<br></div><div>=C2=A0U _member;<br></div><br></div><div>=
=C2=A0I would propose:<br></div><div>=C2=A0template&lt;this T&gt; //real ty=
pe of object (example T const&amp; for cons&amp; funtion<br>
</div>=C2=A0delctype(auto) member() { return std::forward&lt;same_cv_as&lt;=
T, U&gt;&gt;(_member); }; //cv ref deduced\<br><br><div>=C2=A0template&lt;t=
his T&gt; //real type of object<br></div>=C2=A0delctype(auto) member()=C2=
=A0 const { return std::forward&lt;same_cv_as&lt;T, U&gt;&gt;(_member); }; =
//ref deduced, const specified<br>
<br><div>=C2=A0template&lt;this T&gt; //real type of object<br></div>=C2=A0=
delctype(auto) member()=C2=A0 &amp; { return std::forward&lt;same_cv_as&lt;=
T, U&gt;&gt;(_member); }; //cv deduced, ref specified<br><br><div>=C2=A0tem=
plate&lt;this T&gt; //real type of object<br>
</div>=C2=A0delctype(auto) member()=C2=A0 cont &amp; { return std::forward&=
lt;same_cv_as&lt;T, U&gt;&gt;(_member); }; //eror, not think to dedupe<br><=
/div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">2014-07-=
11 9:35 GMT+02:00 Ville Voutilainen <span dir=3D"ltr">&lt;<a href=3D"mailto=
:ville.voutilainen@gmail.com" target=3D"_blank">ville.voutilainen@gmail.com=
</a>&gt;</span>:<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"">On 11 July 2014 08:28, =C2=
=A0&lt;<a href=3D"mailto:tomaszkam@gmail.com">tomaszkam@gmail.com</a>&gt; w=
rote:<br>
&gt; =C2=A0I we add the following r-value overload as originally proposed, =
it will<br>
&gt; have following effect: //as always: optional&lt;T&gt; f();<br>
&gt; =C2=A0 1. *std::forward&lt;U&gt;(u) with optional will actually perfec=
tly forward<br>
&gt; =C2=A0 2. auto&amp;&amp; v =3D f().value() - will still create a dangl=
ing refence (as it it<br>
&gt; will now we two dangling reference), auto will be deduced to T instead=
 of<br>
&gt; T&amp;, but v still we be l-value<br>
&gt; =C2=A0 3. g(f.value()), when g(const T&amp;) accepts by cont&amp; will=
 work the same<br>
&gt; =C2=A0 4. h(f.value()), when h(T) accepts by value, will benefit from =
move<br>
&gt; =C2=A0 5. f().value() =3D 20, will no longer compile if T has l-value =
qualified<br>
&gt; operator=3D(T const&amp;) &amp; //this actullay should be a true<br>
&gt; I found this actually being good not-breaking changes, similar to one<=
br>
&gt; created my adding move constructor to every feasible class in C++11.<b=
r>
&gt; And even adding it to the single optional will not create any surprisi=
ng<br>
&gt; effect in the code<br>
&gt; I think adding such overloads to containers is actually possible, with=
out<br>
&gt; breaking many code.<br>
<br>
<br>
</div>I think we should do what N3982 does with the addition of<br>
const-rvalue-ref-qualified<br>
=C2=A0overloads. With the addition of those, people who care about<br>
forwarding const-rvalues<br>
perfectly will get what they need.<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
--<br>
<br>
---<br>
You received this message because you are subscribed to a topic in the Goog=
le Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/jDRQyBWYl8Q/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/isocpp.org/d/topic/std-proposals/jDRQyBWYl8Q=
/unsubscribe</a>.<br>

To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-proposals+unsubscrib=
e@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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 />

--047d7b5da0937fec0104fde62f14--

.

On 11 July 2014 10:40, Andrzej Krzemie=C5=84ski <akrzemi1@gmail.com> wrote:
> Guys, I just want to summarize what is being discussed here so that every=
one
> is on the same page. We are discussing how overloads operator*() and valu=
e()
> are defined in optional.
>
> Prior to the adoption of N4078, the Fundamentals TS had them as:
> T& operator*();
> T const& operator*() const;
>
>
> T& value();
> T const& value() const;
>
> With the adoption of N4078, Fundamentals TS has:
> T& operator*() &;
> T const& operator*() const&;
> T operator*() &&;            // by value
> T operator*() const&&;       // by value
>
> T& value() &;
> T const& value() const&;
> T value() &&;                // by value
> T value() const&&;           // by value
>
> Now the change that Anna and Tomasz and Ville are considering (an I suppo=
rt)
> is for Fundamentals TS to have:
> T& operator*() &;
> T const& operator*() const&;
> T&& operator*() &&;          // by rvalue ref
>
>
> T& value() &;
> T const& value() const&;
>
> T&& value() &&;                // by rvalue ref
>
> So we are not reverting the change. We change further.
>
> Am I right?

Yes, although the signatures I'm aiming at are in
http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n3982.html


Whether we'll need separate signatures for const T&& needs to be checked wi=
th
LEWG.

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

.

--Apple-Mail=_5C75E495-0790-4076-82F1-E4946CD01250
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8


On 2014=E2=80=9307=E2=80=9311, at 3:40 PM, Andrzej Krzemie=C5=84ski <akrzem=
i1@gmail.com> wrote:

> Guys, I just want to summarize what is being discussed here so that every=
one is on the same page. We are discussing how overloads operator*() and va=
lue() are defined in optional.
>=20
> So we are not reverting the change. We change further.
>=20
> Am I right?

What=E2=80=99s the urgency?

You can still specify the correct behavior using only the lvalue-ref access=
or. Tomasz=E2=80=99 example only looked ugly because no effort was made to =
solve the problem generically or elegantly. It has the same behavior as my =
forward_component utility.

Following up on the request to work with any smart pointer with a prvalue a=
ccessor, a better solution than forward_component would be an idiom effecti=
vely like

 std::forward< decltype( * std::forward< U >( u ) ) >( * u )

However, there are not yet any other operator * () && functions with which =
to interoperate, so users are stuck writing non-generically, and std::optio=
nal might as well go into the same special case as std::unique_ptr.

There=E2=80=99s no reason for the TS to venture into this contentious terri=
tory. The dilemma deserves further review. The problem can be solved later =
without burdening users or harming existing code-bases. There=E2=80=99s no =
sense in putting the cart before the horse with the entire containers and s=
mart-pointers libraries.

TL;DR: The churn is only churn: chasing false constraints around the design=
 space. Return-by-prvalue does not preclude generic forwarding, but the cur=
rent state of containers and smart-pointers does. You=E2=80=99re not going =
to get generic owned-object forwarding in TS1 no matter how you extend opti=
onal::operator*, but you could screw up the library forever.

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

--Apple-Mail=_5C75E495-0790-4076-82F1-E4946CD01250
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;"><br><div><div>On 2014=E2=80=
=9307=E2=80=9311, at 3:40 PM, Andrzej Krzemie=C5=84ski &lt;<a href=3D"mailt=
o:akrzemi1@gmail.com">akrzemi1@gmail.com</a>&gt; wrote:</div><br class=3D"A=
pple-interchange-newline"><blockquote type=3D"cite"><div dir=3D"ltr">Guys,
 I just want to summarize what is being discussed here so that everyone=20
is on the same page. We are discussing how overloads operator*() and=20
value() are defined in optional.<br><div><div><br>So we are not reverting t=
he change. We change further.<br><br>Am I right?<br></div></div></div></blo=
ckquote><div><br></div><div>What=E2=80=99s the urgency?</div><div><br></div=
><div>You can still specify the correct behavior using only the lvalue-ref =
accessor. Tomasz=E2=80=99 example only looked ugly because no effort was ma=
de to solve the problem generically or elegantly. It has the same behavior =
as my <font face=3D"Courier">forward_component</font> utility.</div><div><b=
r></div><div>Following up on the request to work with any smart pointer wit=
h a prvalue accessor, a better solution than <font face=3D"Courier">forward=
_component</font> would be an idiom effectively like</div><div><br></div><d=
iv><span class=3D"Apple-tab-span" style=3D"white-space:pre"> </span><font f=
ace=3D"Courier">std::forward&lt; decltype( * std::forward&lt; U &gt;( u ) )=
 &gt;( * u )</font></div><div><br></div><div>However, there are not yet any=
 other <font face=3D"Courier">operator * () &amp;&amp;</font>&nbsp;function=
s with which to interoperate, so users are stuck writing non-generically, a=
nd&nbsp;<font face=3D"Courier">std::optional</font>&nbsp;might as well go i=
nto the same special case as <font face=3D"Courier">std::unique_ptr</font>.=
</div><div><br></div><div>There=E2=80=99s no reason for the TS to venture i=
nto this contentious territory. The dilemma deserves further review. The pr=
oblem can be solved later without burdening users or harming existing code-=
bases. There=E2=80=99s no sense in putting the cart before the horse with t=
he entire containers and smart-pointers libraries.</div><div><br></div><div=
>TL;DR: The churn is only churn: chasing false constraints around the desig=
n space. Return-by-prvalue does not preclude generic forwarding, but the cu=
rrent state of containers and smart-pointers does. You=E2=80=99re not going=
 to get generic owned-object forwarding in TS1 no matter how you extend <fo=
nt face=3D"Courier">optional::operator*</font>, but you could screw up the =
library forever.</div><div><br></div></div></body></html>

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

--Apple-Mail=_5C75E495-0790-4076-82F1-E4946CD01250--

.

--089e0117692d31a37304fde72573
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Could you please provide me actuall code example that is actually broken by
introduction of T&& operator*() && to existing set of overloads? Id did not
found any in your post, only The generic statment tha will broek the
library/code.


2014-07-11 10:54 GMT+02:00 David Krauss <potswa@gmail.com>:

>
> On 2014=E2=80=9307=E2=80=9311, at 3:40 PM, Andrzej Krzemie=C5=84ski <akrz=
emi1@gmail.com> wrote:
>
> Guys, I just want to summarize what is being discussed here so that
> everyone is on the same page. We are discussing how overloads operator*()
> and value() are defined in optional.
>
> So we are not reverting the change. We change further.
>
> Am I right?
>
>
> What=E2=80=99s the urgency?
>
> You can still specify the correct behavior using only the lvalue-ref
> accessor. Tomasz=E2=80=99 example only looked ugly because no effort was =
made to
> solve the problem generically or elegantly. It has the same behavior as m=
y
> forward_component utility.
>
> Following up on the request to work with any smart pointer with a prvalue
> accessor, a better solution than forward_component would be an idiom
> effectively like
>
> std::forward< decltype( * std::forward< U >( u ) ) >( * u )
>
> However, there are not yet any other operator * () && functions with
> which to interoperate, so users are stuck writing non-generically, and
> std::optional might as well go into the same special case as
> std::unique_ptr.
>
> There=E2=80=99s no reason for the TS to venture into this contentious ter=
ritory.
> The dilemma deserves further review. The problem can be solved later
> without burdening users or harming existing code-bases. There=E2=80=99s n=
o sense in
> putting the cart before the horse with the entire containers and
> smart-pointers libraries.
>
> TL;DR: The churn is only churn: chasing false constraints around the
> design space. Return-by-prvalue does not preclude generic forwarding, but
> the current state of containers and smart-pointers does. You=E2=80=99re n=
ot going
> to get generic owned-object forwarding in TS1 no matter how you extend
> optional::operator*, but you could screw up the library forever.
>
>  --
>
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/jDRQyBWYl8Q/=
unsubscribe
> .
> To unsubscribe from this group and all its topics, 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/.
>

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

--089e0117692d31a37304fde72573
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Could you please provide me actuall code example that is a=
ctually broken by introduction of T&amp;&amp; operator*() &amp;&amp; to exi=
sting set of overloads? Id did not found any in your post, only The generic=
 statment tha will broek the library/code.<br>
</div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">2014-07=
-11 10:54 GMT+02:00 David Krauss <span dir=3D"ltr">&lt;<a href=3D"mailto:po=
tswa@gmail.com" target=3D"_blank">potswa@gmail.com</a>&gt;</span>:<br><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #cc=
c solid;padding-left:1ex">
<div style=3D"word-wrap:break-word"><br><div><div class=3D""><div>On 2014=
=E2=80=9307=E2=80=9311, at 3:40 PM, Andrzej Krzemie=C5=84ski &lt;<a href=3D=
"mailto:akrzemi1@gmail.com" target=3D"_blank">akrzemi1@gmail.com</a>&gt; wr=
ote:</div><br></div><blockquote type=3D"cite">
<div dir=3D"ltr"><div class=3D"">Guys,
 I just want to summarize what is being discussed here so that everyone=20
is on the same page. We are discussing how overloads operator*() and=20
value() are defined in optional.<br></div><div><div><br><div class=3D"">So =
we are not reverting the change. We change further.<br><br>Am I right?<br><=
/div></div></div></div></blockquote><div><br></div><div>What=E2=80=99s the =
urgency?</div>
<div><br></div><div>You can still specify the correct behavior using only t=
he lvalue-ref accessor. Tomasz=E2=80=99 example only looked ugly because no=
 effort was made to solve the problem generically or elegantly. It has the =
same behavior as my <font face=3D"Courier">forward_component</font> utility=
..</div>
<div><br></div><div>Following up on the request to work with any smart poin=
ter with a prvalue accessor, a better solution than <font face=3D"Courier">=
forward_component</font> would be an idiom effectively like</div><div><br>
</div><div><span style=3D"white-space:pre-wrap"> </span><font face=3D"Couri=
er">std::forward&lt; decltype( * std::forward&lt; U &gt;( u ) ) &gt;( * u )=
</font></div><div><br></div><div>However, there are not yet any other <font=
 face=3D"Courier">operator * () &amp;&amp;</font>=C2=A0functions with which=
 to interoperate, so users are stuck writing non-generically, and=C2=A0<fon=
t face=3D"Courier">std::optional</font>=C2=A0might as well go into the same=
 special case as <font face=3D"Courier">std::unique_ptr</font>.</div>
<div><br></div><div>There=E2=80=99s no reason for the TS to venture into th=
is contentious territory. The dilemma deserves further review. The problem =
can be solved later without burdening users or harming existing code-bases.=
 There=E2=80=99s no sense in putting the cart before the horse with the ent=
ire containers and smart-pointers libraries.</div>
<div><br></div><div>TL;DR: The churn is only churn: chasing false constrain=
ts around the design space. Return-by-prvalue does not preclude generic for=
warding, but the current state of containers and smart-pointers does. You=
=E2=80=99re not going to get generic owned-object forwarding in TS1 no matt=
er how you extend <font face=3D"Courier">optional::operator*</font>, but yo=
u could screw up the library forever.</div>
<div><br></div></div></div><div class=3D"HOEnZb"><div class=3D"h5">

<p></p>

-- <br>
<br>
--- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/jDRQyBWYl8Q/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/isocpp.org/d/topic/std-proposals/jDRQyBWYl8Q=
/unsubscribe</a>.<br>

To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_blank">std-prop=
osals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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 />

--089e0117692d31a37304fde72573--

.

On 2014=E2=80=9307=E2=80=9311, at 4:58 PM, Tomasz Kami=C5=84ski <tomaszkam@=
gmail.com> wrote:

> Could you please provide me actuall code example that is actually broken =
by introduction of T&& operator*() && to existing set of overloads? Id did =
not found any in your post, only The generic statment tha will broek the li=
brary/code.

As was discussed earlier, return-by-xvalue does not work with local univers=
al references. Universal references are not just a cute thing that trendy p=
rogrammers like to sprinkle around, they provide a way for generic code to =
bind a name to something which may or may not be a reference.

--=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_100_24973738.1405069420944
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



On Friday, July 11, 2014 9:40:16 AM UTC+2, Andrzej Krzemie=C5=84ski wrote:
>
> So we are not reverting the change. We change further.
>
> Am I right?
>
>
I think you are. Though do we still need the & overload if we've got the &&=
=20
overload?=20

--=20

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

------=_Part_100_24973738.1405069420944
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Friday, July 11, 2014 9:40:16 AM UTC+2, Andrzej=
 Krzemie=C5=84ski wrote:<blockquote class=3D"gmail_quote" style=3D"margin: =
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div d=
ir=3D"ltr">So we are not reverting the change. We change further.<br><br>Am=
 I right?<br><br></div></blockquote><div><br></div><div>I think you are. Th=
ough do we still need the &amp; overload if we've got the &amp;&amp; overlo=
ad?&nbsp;</div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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_100_24973738.1405069420944--

.

--f46d0442848452aaee04fde7416a
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

2014-07-11 11:03 GMT+02:00 Olaf van der Spek <olafvdspek@gmail.com>:

>
>
> On Friday, July 11, 2014 9:40:16 AM UTC+2, Andrzej Krzemie=C5=84ski wrote=
:
>>
>> So we are not reverting the change. We change further.
>>
>> Am I right?
>>
>>
> I think you are. Though do we still need the & overload if we've got the
> && overload?
>

sure we do. E.g. in order to allow the following use case:

optiona<int> oi =3D readVal();
if (oi && *oi < 0) *oi =3D 0;
return oi;

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

--f46d0442848452aaee04fde7416a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">2014-07-11 11:03 GMT+02:00 Olaf van der Spek <span dir=3D"ltr">&lt;=
<a href=3D"mailto:olafvdspek@gmail.com" target=3D"_blank">olafvdspek@gmail.=
com</a>&gt;</span>:<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""><br><br>On =
Friday, July 11, 2014 9:40:16 AM UTC+2, Andrzej Krzemie=C5=84ski 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">So we are not reverting the change. We change further.<br>=
<br>Am I right?<br><br></div></blockquote><div><br></div></div><div>I think=
 you are. Though do we still need the &amp; overload if we&#39;ve got the &=
amp;&amp; overload?=C2=A0</div>
</div></blockquote><div><br></div><div>sure we do. E.g. in order to allow t=
he following use case:<br><br></div><div>optiona&lt;int&gt; oi =3D readVal(=
);<br></div><div>if (oi &amp;&amp; *oi &lt; 0) *oi =3D 0;<br></div><div>ret=
urn oi; <br>
</div></div><br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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 />

--f46d0442848452aaee04fde7416a--

.

--e89a8fb1ed1cb8109c04fde7469d
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

But thsi still does not work with current overloads, sot this will not
broken. I naddition usign auto&& in geeneric code witll end up creatign
dnagling reference if you have captures by valui some expression template
(and even operator auto/using auot) will not prevent you from that. auto&&
Or even capture refernce_wrapper.

Please see my example with result of array fo 100 elements with additional
reference to best in this array. The auto&& canot be make to be working in
generic context.

But actually doing:
wiht(expr, [](auto&& cs) { code taht uses it });
Will fix every dangling reference. Or:
auto f =3D []() -> delctype(auto) { return /*some long expr*/l }
somelongexprtakingbeforeresultbrokeninparts(f());


2014-07-11 11:02 GMT+02:00 David Krauss <potswa@gmail.com>:

>
> On 2014=E2=80=9307=E2=80=9311, at 4:58 PM, Tomasz Kami=C5=84ski <tomaszka=
m@gmail.com> wrote:
>
> > Could you please provide me actuall code example that is actually broke=
n
> by introduction of T&& operator*() && to existing set of overloads? Id di=
d
> not found any in your post, only The generic statment tha will broek the
> library/code.
>
> As was discussed earlier, return-by-xvalue does not work with local
> universal references. Universal references are not just a cute thing that
> trendy programmers like to sprinkle around, they provide a way for generi=
c
> code to bind a name to something which may or may not be a reference.
>
> --
>
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/jDRQyBWYl8Q/=
unsubscribe
> .
> To unsubscribe from this group and all its topics, 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/.
>

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

--e89a8fb1ed1cb8109c04fde7469d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div><div><div><div>But thsi still does not work with=
 current overloads, sot this will not broken. I naddition usign auto&amp;&a=
mp; in geeneric code witll end up creatign dnagling reference if you have c=
aptures by valui some expression template (and even operator auto/using auo=
t) will not prevent you from that. auto&amp;&amp; Or even capture refernce_=
wrapper.<br>
<br></div><div>Please see my example with result of array fo 100 elements w=
ith additional reference to best in this array. The auto&amp;&amp; canot be=
 make to be working in generic context.<br></div><div><br></div>But actuall=
y doing:<br>
</div>wiht(expr, [](auto&amp;&amp; cs) { code taht uses it }); <br></div>Wi=
ll fix every dangling reference. Or:<br></div>auto f =3D []() -&gt; delctyp=
e(auto) { return /*some long expr*/l }<br></div>somelongexprtakingbeforeres=
ultbrokeninparts(f());<br>
</div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">2014-07=
-11 11:02 GMT+02:00 David Krauss <span dir=3D"ltr">&lt;<a href=3D"mailto:po=
tswa@gmail.com" target=3D"_blank">potswa@gmail.com</a>&gt;</span>:<br><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #cc=
c solid;padding-left:1ex">
<div class=3D""><br>
On 2014=E2=80=9307=E2=80=9311, at 4:58 PM, Tomasz Kami=C5=84ski &lt;<a href=
=3D"mailto:tomaszkam@gmail.com">tomaszkam@gmail.com</a>&gt; wrote:<br>
<br>
&gt; Could you please provide me actuall code example that is actually brok=
en by introduction of T&amp;&amp; operator*() &amp;&amp; to existing set of=
 overloads? Id did not found any in your post, only The generic statment th=
a will broek the library/code.<br>

<br>
</div>As was discussed earlier, return-by-xvalue does not work with local u=
niversal references. Universal references are not just a cute thing that tr=
endy programmers like to sprinkle around, they provide a way for generic co=
de to bind a name to something which may or may not be a reference.<br>

<div class=3D"HOEnZb"><div class=3D"h5"><br>
--<br>
<br>
---<br>
You received this message because you are subscribed to a topic in the Goog=
le Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/jDRQyBWYl8Q/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/isocpp.org/d/topic/std-proposals/jDRQyBWYl8Q=
/unsubscribe</a>.<br>

To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-proposals+unsubscrib=
e@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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 />

--e89a8fb1ed1cb8109c04fde7469d--

.

--f46d0444ed5fcaf26204fde74d1a
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

2014-07-11 11:02 GMT+02:00 David Krauss <potswa@gmail.com>:

>
> On 2014=E2=80=9307=E2=80=9311, at 4:58 PM, Tomasz Kami=C5=84ski <tomaszka=
m@gmail.com> wrote:
>
> > Could you please provide me actuall code example that is actually broke=
n
> by introduction of T&& operator*() && to existing set of overloads? Id di=
d
> not found any in your post, only The generic statment tha will broek the
> library/code.
>
> As was discussed earlier, return-by-xvalue does not work with local
> universal references. Universal references are not just a cute thing that
> trendy programmers like to sprinkle around, they provide a way for generi=
c
> code to bind a name to something which may or may not be a reference.
>

David, would it be possible to illustrate with an example what you mean
here?

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

--f46d0444ed5fcaf26204fde74d1a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">2014-07-11 11:02 GMT+02:00 David Krauss <span dir=3D"ltr">&lt;<a hr=
ef=3D"mailto:potswa@gmail.com" target=3D"_blank">potswa@gmail.com</a>&gt;</=
span>:<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""><br>
On 2014=E2=80=9307=E2=80=9311, at 4:58 PM, Tomasz Kami=C5=84ski &lt;<a href=
=3D"mailto:tomaszkam@gmail.com">tomaszkam@gmail.com</a>&gt; wrote:<br>
<br>
&gt; Could you please provide me actuall code example that is actually brok=
en by introduction of T&amp;&amp; operator*() &amp;&amp; to existing set of=
 overloads? Id did not found any in your post, only The generic statment th=
a will broek the library/code.<br>

<br>
</div>As was discussed earlier, return-by-xvalue does not work with local u=
niversal references. Universal references are not just a cute thing that tr=
endy programmers like to sprinkle around, they provide a way for generic co=
de to bind a name to something which may or may not be a reference.<br>
</blockquote><div><br></div><div>David, would it be possible to illustrate =
with an example what you mean here?<br></div></div><br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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 />

--f46d0444ed5fcaf26204fde74d1a--

.

On 10 July 2014 14:12, David Krauss <potswa@gmail.com> wrote:
> Strange, I didn=E2=80=99t realize that const& is preferred over && for a =
const
> rvalue implicit argument, but so it is. GCC even fails to prefer const&&
> over const&.


Just FYI, this has been fixed in GCC recently.

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

.

On 11 July 2014 11:54, David Krauss <potswa@gmail.com> wrote:
> There=E2=80=99s no reason for the TS to venture into this contentious ter=
ritory. The

There's every reason to do so - that's what TSs are for. Whether the actual
standard ventures into that territory is another matter, and the TS will pr=
ovide
useful input for that.

--=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_117_13150077.1405070784540
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

But this still does not work with current overloads, so it wont be broken.=
=20

In addition the auto&& will never work with expression templates even if=20
operator auto/using auto is introduced. If we have a matrix class that uses=
=20
expression templates for multuplication the following
expression m1*m2 will return object by value (mult_result) that stores=20
references so following:
  auto s =3D m1*m2;
  auto&& s =3D m1*m2;
Will not work, becuase the object referenced by mult_result will be=20
destroyed by end of expression. The operator auto fixes only the first case=
..

But actually doing:
with(expr, [](auto&& cs) { /*code that uses it*/ });=20
Will fix every dangling reference.
Or:
auto f =3D []() -> delctype(auto) { return /*some long expr*/l }
somelongexprtakingbeforeresultbrokeninparts(f());
Becuaxse all temporary objects and code that uses it will be run in single=
=20
expression.


W dniu pi=C4=85tek, 11 lipca 2014 11:02:08 UTC+2 u=C5=BCytkownik David Krau=
ss napisa=C5=82:
>
>
> On 2014=E2=80=9307=E2=80=9311, at 4:58 PM, Tomasz Kami=C5=84ski <toma...@=
gmail.com=20
> <javascript:>> wrote:=20
>
> > Could you please provide me actuall code example that is actually broke=
n=20
> by introduction of T&& operator*() && to existing set of overloads? Id di=
d=20
> not found any in your post, only The generic statment tha will broek the=
=20
> library/code.=20
>
> As was discussed earlier, return-by-xvalue does not work with local=20
> universal references. Universal references are not just a cute thing that=
=20
> trendy programmers like to sprinkle around, they provide a way for generi=
c=20
> code to bind a name to something which may or may not be a reference.=20
>
>

--=20

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

------=_Part_117_13150077.1405070784540
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><div><div><div><div><div>But this still d=
oes not work=20
with current overloads, so it wont be broken. <br><br>In addition the auto&=
amp;&amp; will never work with expression templates even if operator auto/u=
sing auto is introduced. If we have a matrix class that uses expression tem=
plates for multuplication the following<br>expression m1*m2 will return obj=
ect by value (mult_result) that stores references so following:<br>&nbsp; a=
uto s =3D m1*m2;<br>&nbsp; auto&amp;&amp; s =3D m1*m2;<br>Will not work, be=
cuase the object referenced by mult_result will be destroyed by end of expr=
ession. The operator auto fixes only the first case.<br><br></div>But actua=
lly doing:<br>
</div>with(expr, [](auto&amp;&amp; cs) { /*code that uses it*/ }); <br></di=
v>Will fix every dangling reference.<br>Or:<br></div>auto f =3D []() -&gt; =
delctype(auto) { return /*some long expr*/l }<br></div>somelongexprtakingbe=
foreresult<wbr>brokeninparts(f());<br>
</div>Becuaxse all temporary objects and code that uses it will be run in s=
ingle expression.<br><br><br>W dniu pi=C4=85tek, 11 lipca 2014 11:02:08 UTC=
+2 u=C5=BCytkownik David Krauss napisa=C5=82:<blockquote class=3D"gmail_quo=
te" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddi=
ng-left: 1ex;">
<br>On 2014=E2=80=9307=E2=80=9311, at 4:58 PM, Tomasz Kami=C5=84ski &lt;<a =
href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"zJOvvgqpbWo=
J" onmousedown=3D"this.href=3D'javascript:';return true;" onclick=3D"this.h=
ref=3D'javascript:';return true;">toma...@gmail.com</a>&gt; wrote:
<br>
<br>&gt; Could you please provide me actuall code example that is actually =
broken by introduction of T&amp;&amp; operator*() &amp;&amp; to existing se=
t of overloads? Id did not found any in your post, only The generic statmen=
t tha will broek the library/code.
<br>
<br>As was discussed earlier, return-by-xvalue does not work with local uni=
versal references. Universal references are not just a cute thing that tren=
dy programmers like to sprinkle around, they provide a way for generic code=
 to bind a name to something which may or may not be a reference.
<br>
<br></blockquote></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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_117_13150077.1405070784540--

.

--Apple-Mail=_5DB44DB9-2EAB-46AD-AF6E-4FB2EB298B76
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1


On 2014-07-11, at 5:09 PM, Andrzej Krzemienski <akrzemi1@gmail.com> wrote:

> 2014-07-11 11:02 GMT+02:00 David Krauss <potswa@gmail.com>:
> As was discussed earlier, return-by-xvalue does not work with local unive=
rsal references. Universal references are not just a cute thing that trendy=
 programmers like to sprinkle around, they provide a way for generic code t=
o bind a name to something which may or may not be a reference.
>=20
> David, would it be possible to illustrate with an example what you mean h=
ere?

template< typename container_handle >
void operate_on_fifth_thing( container_handle && ch ) {
    // Save only the fifth element. We don't need the rest; OK to free thos=
e resources.
    auto && fifth_thing =3D=3D ( * std::forward< container_handle >( ch ) )=
[ 5 ];

    // This is illustrated as a function call, but there might as well be a=
 loop here.
    process_for_a_long_time( std::forward< decltype( thing ) >( fifth_thing=
 ) );
}

I don't think this is far-fetched at all, aside from presupposing rvalue-ov=
erloaded operator* and operator[].

You generally might do the same things with a named object as with a tempor=
ary. "Forwarding contexts" don't all end at the semicolon.

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

--Apple-Mail=_5DB44DB9-2EAB-46AD-AF6E-4FB2EB298B76
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014&=
ndash;07&ndash;11, at 5:09 PM, Andrzej Krzemienski &lt;<a href=3D"mailto:ak=
rzemi1@gmail.com">akrzemi1@gmail.com</a>&gt; wrote:</div><br class=3D"Apple=
-interchange-newline"><blockquote type=3D"cite"><div dir=3D"ltr">2014-07-11=
 11:02 GMT+02:00 David Krauss <span dir=3D"ltr">&lt;<a href=3D"mailto:potsw=
a@gmail.com" target=3D"_blank">potswa@gmail.com</a>&gt;</span>:<br><div cla=
ss=3D"gmail_extra"><div class=3D"gmail_quote">
<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; borde=
r-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style=
: solid; padding-left: 1ex; position: static; z-index: auto;"><div class=3D=
"">As was discussed earlier, return-by-xvalue does not work with local univ=
ersal references. Universal references are not just a cute thing that trend=
y programmers like to sprinkle around, they provide a way for generic code =
to bind a name to something which may or may not be a reference.</div>
</blockquote><div><br></div><div>David, would it be possible to illustrate =
with an example what you mean here?<br></div></div></div></div></blockquote=
></div><br><div><font face=3D"Courier">template&lt; typename container_hand=
le &gt;</font></div><div><font face=3D"Courier">void operate_on_fifth_thing=
( container_handle &amp;&amp; ch ) {</font></div><div><font face=3D"Courier=
">&nbsp; &nbsp; // Save only the fifth element. We don&rsquo;t need the res=
t; OK to free those resources.</font></div><div><font face=3D"Courier">&nbs=
p; &nbsp; auto &amp;&amp; fifth_thing =3D=3D ( * std::forward&lt; container=
_handle &gt;( ch ) )[ 5 ];</font></div><div><font face=3D"Courier"><br></fo=
nt></div><div><font face=3D"Courier">&nbsp; &nbsp; // This is illustrated a=
s a function call, but there might as well be a loop here.</font></div><div=
><font face=3D"Courier">&nbsp; &nbsp; process_for_a_long_time( std::forward=
&lt; decltype( thing ) &gt;( fifth_thing ) );</font></div><div><font face=
=3D"Courier">}</font></div><div><br></div><div>I don&rsquo;t think this is =
far-fetched at all, aside from presupposing rvalue-overloaded <font face=3D=
"Courier">operator*</font> and <font face=3D"Courier">operator[]</font>.</d=
iv><div><br></div><div>You generally might do the same things with a named =
object as with a temporary. &ldquo;Forwarding contexts&rdquo; don&rsquo;t a=
ll end at the semicolon.</div><div><br></div></body></html>

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

--Apple-Mail=_5DB44DB9-2EAB-46AD-AF6E-4FB2EB298B76--

.

On 11 July 2014 12:29, David Krauss <potswa@gmail.com> wrote:
> On 2014=E2=80=9307=E2=80=9311, at 5:09 PM, Andrzej Krzemienski <akrzemi1@=
gmail.com> wrote:
> 2014-07-11 11:02 GMT+02:00 David Krauss <potswa@gmail.com>:
>>
>> As was discussed earlier, return-by-xvalue does not work with local
>> universal references. Universal references are not just a cute thing tha=
t
>> trendy programmers like to sprinkle around, they provide a way for gener=
ic
>> code to bind a name to something which may or may not be a reference.
> David, would it be possible to illustrate with an example what you mean
> here?
>
>
> template< typename container_handle >
> void operate_on_fifth_thing( container_handle && ch ) {
>     // Save only the fifth element. We don=E2=80=99t need the rest; OK to=
 free those
> resources.
>     auto && fifth_thing =3D=3D ( * std::forward< container_handle >( ch )=
 )[ 5
> ];
>
>     // This is illustrated as a function call, but there might as well be=
 a
> loop here.
>     process_for_a_long_time( std::forward< decltype( thing ) >( fifth_thi=
ng
> ) );
> }
>
> I don=E2=80=99t think this is far-fetched at all, aside from presupposing
> rvalue-overloaded operator* and operator[].
>
> You generally might do the same things with a named object as with a
> temporary. =E2=80=9CForwarding contexts=E2=80=9D don=E2=80=99t all end at=
 the semicolon.


Why is that code using auto&&?

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

.

--Apple-Mail=_D9B675E4-E67D-49EA-A350-7A0FA65E0481
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1


On 2014-07-11, at 5:09 PM, Andrzej Krzemienski <akrzemi1@gmail.com> wrote:

> 2014-07-11 11:02 GMT+02:00 David Krauss <potswa@gmail.com>:
> As was discussed earlier, return-by-xvalue does not work with local unive=
rsal references. Universal references are not just a cute thing that trendy=
 programmers like to sprinkle around, they provide a way for generic code t=
o bind a name to something which may or may not be a reference.
>=20
> David, would it be possible to illustrate with an example what you mean h=
ere?


I've adjusted the comments slightly, just for exposition of what forwarding=
 in this case actually does.

template< typename container_handle >
void operate_on_fifth_thing( container_handle && ch ) {
    // Get only the fifth element. We don't need the rest; OK to free those=
 resources.
    // However, if not assuming ownership, there's no need to make a copy.
    auto && fifth_thing =3D=3D ( * std::forward< container_handle >( ch ) )=
[ 5 ];

    // This is illustrated as a function call, but there might as well be a=
 loop here.
    process_for_a_long_time( std::forward< decltype( thing ) >( fifth_thing=
 ) );
}

I don't think this is far-fetched at all, aside from presupposing rvalue-ov=
erloaded operator* and operator[].

You generally might do the same things with a named object as with a tempor=
ary. "Forwarding contexts" don't all end at the semicolon.

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

--Apple-Mail=_D9B675E4-E67D-49EA-A350-7A0FA65E0481
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"><meta http-equiv=3D"Content-Type" content=3D"text/html cha=
rset=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-n=
bsp-mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2=
014&ndash;07&ndash;11, at 5:09 PM, Andrzej Krzemienski &lt;<a href=3D"mailt=
o:akrzemi1@gmail.com">akrzemi1@gmail.com</a>&gt; wrote:</div><br class=3D"A=
pple-interchange-newline"><blockquote type=3D"cite"><div dir=3D"ltr">2014-0=
7-11 11:02 GMT+02:00 David Krauss <span dir=3D"ltr">&lt;<a href=3D"mailto:p=
otswa@gmail.com" target=3D"_blank">potswa@gmail.com</a>&gt;</span>:<br><div=
 class=3D"gmail_extra"><div class=3D"gmail_quote">
<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; borde=
r-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style=
: solid; padding-left: 1ex; position: static; z-index: auto;"><div class=3D=
"">As was discussed earlier, return-by-xvalue does not work with local univ=
ersal references. Universal references are not just a cute thing that trend=
y programmers like to sprinkle around, they provide a way for generic code =
to bind a name to something which may or may not be a reference.</div>
</blockquote><div><br></div><div>David, would it be possible to illustrate =
with an example what you mean here?<br></div></div></div></div></blockquote=
></div><div><br></div><div>I&rsquo;ve adjusted the comments slightly, just =
for exposition of what forwarding in this case actually does.</div><br><div=
><font face=3D"Courier">template&lt; typename container_handle &gt;</font><=
/div><div><font face=3D"Courier">void operate_on_fifth_thing( container_han=
dle &amp;&amp; ch ) {</font></div><div><font face=3D"Courier">&nbsp; &nbsp;=
 // Get only the fifth element. We don&rsquo;t need the rest; OK to free th=
ose resources.</font></div><div><font face=3D"Courier">&nbsp; &nbsp; // How=
ever, if not assuming ownership, there&rsquo;s no need to make a&nbsp;copy.=
</font></div><div><font face=3D"Courier">&nbsp; &nbsp; auto &amp;&amp; fift=
h_thing =3D=3D ( * std::forward&lt; container_handle &gt;( ch ) )[ 5 ];</fo=
nt></div><div><font face=3D"Courier"><br></font></div><div><font face=3D"Co=
urier">&nbsp; &nbsp; // This is illustrated as a function call, but there m=
ight as well be a loop here.</font></div><div><font face=3D"Courier">&nbsp;=
 &nbsp; process_for_a_long_time( std::forward&lt; decltype( thing ) &gt;( f=
ifth_thing ) );</font></div><div><font face=3D"Courier">}</font></div><div>=
<br></div><div>I don&rsquo;t think this is far-fetched at all, aside from p=
resupposing rvalue-overloaded <font face=3D"Courier">operator*</font> and <=
font face=3D"Courier">operator[]</font>.</div><div><br></div><div>You gener=
ally might do the same things with a named object as with a temporary. &ldq=
uo;Forwarding contexts&rdquo; don&rsquo;t all end at the semicolon.</div><d=
iv><br></div></body></html>

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

--Apple-Mail=_D9B675E4-E67D-49EA-A350-7A0FA65E0481--

.

On 2014-07-11, at 5:34 PM, Ville Voutilainen <ville.voutilainen@gmail.com> wrote:

> Why is that code using auto&&?

Can you rewrite it with any other substitute?

--

---
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_171_5218154.1405071904604
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



W dniu pi=C4=85tek, 11 lipca 2014 11:29:50 UTC+2 u=C5=BCytkownik David Krau=
ss napisa=C5=82:
>
>
> On 2014=E2=80=9307=E2=80=9311, at 5:09 PM, Andrzej Krzemienski <akrz...@g=
mail.com=20
> <javascript:>> wrote:
>
> 2014-07-11 11:02 GMT+02:00 David Krauss <pot...@gmail.com <javascript:>>:
>
>> As was discussed earlier, return-by-xvalue does not work with local=20
>> universal references. Universal references are not just a cute thing tha=
t=20
>> trendy programmers like to sprinkle around, they provide a way for gener=
ic=20
>> code to bind a name to something which may or may not be a reference.
>>
>
> David, would it be possible to illustrate with an example what you mean=
=20
> here?
>
>
> template< typename container_handle >
> void operate_on_fifth_thing( container_handle && ch ) {
>     // Save only the fifth element. We don=E2=80=99t need the rest; OK to=
 free=20
> those resources.
>     auto && fifth_thing =3D=3D ( * std::forward< container_handle >( ch )=
 )[ 5=20
> ];
>
>     // This is illustrated as a function call, but there might as well be=
=20
> a loop here.
>     process_for_a_long_time( std::forward< decltype( thing ) >(=20
> fifth_thing ) );
> }
>
> I don=E2=80=99t think this is far-fetched at all, aside from presupposing=
=20
> rvalue-overloaded operator* and operator[].
>
> You generally might do the same things with a named object as with a=20
> temporary. =E2=80=9CForwarding contexts=E2=80=9D don=E2=80=99t all end at=
 the semicolon.
>
> And how actually changing the result of ( * std::forward<=20
container_handle >( ch ) )[ 5 ]; form T& to T&& in some situation will=20
break above code.=20
1) The fith_ing will still be lvalue of type T for the loop case.
2)   If the process process_for_a_long_time takes a T by value then we will=
=20
benefit from move.
3) If the process process_for_a_long_time takes a const T& then nothing=20
will change
4) If the process process_for_a_long_time takes a T& yhe code will cause=20
compiler error - this is good becuase you will detect case of editing=20
temporary (this is why (f(std::string&) is not accepthing temproary). If=20
you still want following case to work use:
  process_for_a_long_time( fifth_thing ) because you actually down ant to=
=20
perfectly fowrad rvalues.

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

<div dir=3D"ltr"><br><br>W dniu pi=C4=85tek, 11 lipca 2014 11:29:50 UTC+2 u=
=C5=BCytkownik David Krauss napisa=C5=82:<blockquote class=3D"gmail_quote" =
style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-l=
eft: 1ex;"><div style=3D"word-wrap:break-word"><br><div><div>On 2014=E2=80=
=9307=E2=80=9311, at 5:09 PM, Andrzej Krzemienski &lt;<a href=3D"javascript=
:" target=3D"_blank" gdf-obfuscated-mailto=3D"db_EVj1FvXsJ" onmousedown=3D"=
this.href=3D'javascript:';return true;" onclick=3D"this.href=3D'javascript:=
';return true;">akrz...@gmail.com</a>&gt; wrote:</div><br><blockquote type=
=3D"cite"><div dir=3D"ltr">2014-07-11 11:02 GMT+02:00 David Krauss <span di=
r=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mail=
to=3D"db_EVj1FvXsJ" onmousedown=3D"this.href=3D'javascript:';return true;" =
onclick=3D"this.href=3D'javascript:';return true;">pot...@gmail.com</a>&gt;=
</span>:<br><div><div class=3D"gmail_quote">
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex"><div>As was discussed earlier, return-by-xvalue does not w=
ork with local universal references. Universal references are not just a cu=
te thing that trendy programmers like to sprinkle around, they provide a wa=
y for generic code to bind a name to something which may or may not be a re=
ference.</div>
</blockquote><div><br></div><div>David, would it be possible to illustrate =
with an example what you mean here?<br></div></div></div></div></blockquote=
></div><br><div><font face=3D"Courier">template&lt; typename container_hand=
le &gt;</font></div><div><font face=3D"Courier">void operate_on_fifth_thing=
( container_handle &amp;&amp; ch ) {</font></div><div><font face=3D"Courier=
">&nbsp; &nbsp; // Save only the fifth element. We don=E2=80=99t need the r=
est; OK to free those resources.</font></div><div><font face=3D"Courier">&n=
bsp; &nbsp; auto &amp;&amp; fifth_thing =3D=3D ( * std::forward&lt; contain=
er_handle &gt;( ch ) )[ 5 ];</font></div><div><font face=3D"Courier"><br></=
font></div><div><font face=3D"Courier">&nbsp; &nbsp; // This is illustrated=
 as a function call, but there might as well be a loop here.</font></div><d=
iv><font face=3D"Courier">&nbsp; &nbsp; process_for_a_long_time( std::forwa=
rd&lt; decltype( thing ) &gt;( fifth_thing ) );</font></div><div><font face=
=3D"Courier">}</font></div><div><br></div><div>I don=E2=80=99t think this i=
s far-fetched at all, aside from presupposing rvalue-overloaded <font face=
=3D"Courier">operator*</font> and <font face=3D"Courier">operator[]</font>.=
</div><div><br></div><div>You generally might do the same things with a nam=
ed object as with a temporary. =E2=80=9CForwarding contexts=E2=80=9D don=E2=
=80=99t all end at the semicolon.</div><div><br></div></div></blockquote><d=
iv>And how actually changing the result of <font face=3D"Courier">( * std::=
forward&lt; container_handle &gt;( ch ) )[ 5 ]; form T&amp; to T&amp;&amp; =
in some situation will break above code. <br>1) The fith_ing will still be =
lvalue of type T for the loop case.<br></font>2)&nbsp;&nbsp; If the process=
 <font face=3D"Courier">process_for_a_long_time takes a T by value then we =
will benefit from move.<br>3) </font> If the process <font face=3D"Courier"=
>process_for_a_long_time takes a const T&amp; then nothing will change<br>4=
) </font> If the process <font face=3D"Courier">process_for_a_long_time tak=
es a T&amp; yhe code will cause compiler error - this is good becuase you w=
ill detect case of editing <br>temporary (this is why (f(std::string&amp;) =
is not accepthing temproary). If you still want following case to work use:=
<br>&nbsp; </font><font face=3D"Courier">process_for_a_long_time(</font> <f=
ont face=3D"Courier">fifth_thing ) because you actually down ant to perfect=
ly fowrad rvalues.</font><br><br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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_171_5218154.1405071904604--

.

On 11 July 2014 12:36, David Krauss <potswa@gmail.com> wrote:
>
> On 2014-07-11, at 5:34 PM, Ville Voutilainen <ville.voutilainen@gmail.com> wrote:
>
>> Why is that code using auto&&?
>
> Can you rewrite it with any other substitute?


That would depend on the answer to the question. The container is not
going out of scope,
so I don't see why the auto&& should bind to a prvalue, so it's
unclear whether it does or
does not need to worry about an xvalue. None of the things in the
current library give you
prvalues from temporaries, so if we want to talk about consistency,
optional shouldn't
do that either.

There's a fair amount of non-standard libraries where writing even

const T& foo = thing.getBuffer().toString();

will give you a dangling reference. Writing

auto&& bar = punish().me().harder();

doesn't work, in general, and any magic that would make parts of it
work should not be optional-only.

To reiterate, yes, T -> T&& is the thing to do for Fundamentals v1. None of the
auto&& cases are broken by changing from the previous T&/const T& to
T&/const T/T&&.
Some auto&& cases are broken by changing from T to T&&. That's a
balancing call, since
having T as the return type breaks emplace, and it does make
forwarding harder, regardless
of expert's ability to write forward_component.

I see nothing new that would be convincing to change the understanding
I have about what
we should do for the rvalue-ref-qualified observer overloads of optional.

--

---
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_125_29749322.1405072149647
Content-Type: text/plain; charset=UTF-8

Acutall case does even need susbtitute:
template< typename container_handle >
void operate_on_fifth_thing( container_handle && ch ) {
  process_for_a_long_time( * std::forward< container_handle >( ch ) )[ 5 ]
);
}

That willl work with any body:
template<typename T, typename F>
void with(T&& t, FV&& fv) { std::forward<FV>(fv)(std::forward<T>(t)); }

template< typename container_handle >
void operate_on_fifth_thing( container_handle && ch ) {
    with(( * std::forward< container_handle >( ch ) )[ 5 ], [](auto &&
fifth_thing) {
      // This is illustrated as a function call, but there might as well be
a loop here.
      process_for_a_long_time( std::forward< decltype( thing ) >(
fifth_thing ) );
    });
}

--

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

<div dir=3D"ltr"><div class=3D"GGCIKMHDGHB">Acutall case does even need sus=
btitute:<br><div><font face=3D"Courier">template&lt; typename container_han=
dle &gt;</font></div><div><font face=3D"Courier">void operate_on_fifth_thin=
g( container_handle &amp;&amp; ch ) {</font></div><div><font face=3D"Courie=
r">&nbsp; process_for_a_long_time( </font><font face=3D"Courier"><font face=
=3D"Courier">* std::forward&lt; container_handle &gt;( ch ) )[ 5 ]</font> )=
;<br></font></div><div><font face=3D"Courier">}</font></div><br>That willl =
work with any body:<br>template&lt;typename T, typename F&gt;<br>void with(=
T&amp;&amp; t, FV&amp;&amp; fv) { std::forward&lt;FV&gt;(fv)(std::forward&l=
t;T&gt;(t)); }<br><br><div><font face=3D"Courier">template&lt; typename con=
tainer_handle &gt;</font></div><div><font face=3D"Courier">void operate_on_=
fifth_thing( container_handle &amp;&amp; ch ) {<br>&nbsp;&nbsp;&nbsp; with(=
</font><font face=3D"Courier">( * std::forward&lt; container_handle &gt;( c=
h ) )[ 5 ], [](</font><font face=3D"Courier">auto &amp;&amp; fifth_thing) {=
<br></font></div></div><div><font face=3D"Courier"></font></div><div><font =
face=3D"Courier">&nbsp; &nbsp; &nbsp; // This is illustrated as a function =
call, but there might as well be a loop here.</font></div><div><font face=
=3D"Courier">&nbsp; &nbsp; &nbsp; process_for_a_long_time( std::forward&lt;=
 decltype( thing ) &gt;( fifth_thing ) );<br>&nbsp;&nbsp;&nbsp; });<br></fo=
nt></div><div><font face=3D"Courier">}</font></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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_125_29749322.1405072149647--

.

------=_Part_154_13869155.1405072585090
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

And the really funny think. Your code will not work if container_handle is=
=20
a lazy evaluator and * std::forward< container_handle >( ch ) acutally=20
returns the container by value, ortogonalny to the fact if we have &&=20
overloads and the solutions presented by me will actually fix the code.=20
Because the * std::forward< container_handle >( ch ) will be created and=20
used in one expression. The auto&& will create dangling reference.

W dniu pi=C4=85tek, 11 lipca 2014 11:49:09 UTC+2 u=C5=BCytkownik toma...@gm=
ail.com=20
napisa=C5=82:
>
> Acutall case does even need susbtitute:
> template< typename container_handle >
> void operate_on_fifth_thing( container_handle && ch ) {
>   process_for_a_long_time( * std::forward< container_handle >( ch ) )[ 5 =
]=20
> );
> }
>
> That willl work with any body:
> template<typename T, typename F>
> void with(T&& t, FV&& fv) { std::forward<FV>(fv)(std::forward<T>(t)); }
>
> template< typename container_handle >
> void operate_on_fifth_thing( container_handle && ch ) {
>     with(( * std::forward< container_handle >( ch ) )[ 5 ], [](auto &&=20
> fifth_thing) {
>       // This is illustrated as a function call, but there might as well=
=20
> be a loop here.
>       process_for_a_long_time( std::forward< decltype( thing ) >(=20
> fifth_thing ) );
>     });
> }
>

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

<div dir=3D"ltr">And the really funny think. Your code will not work if con=
tainer_handle is a lazy evaluator and <font face=3D"Courier">* std::forward=
&lt; container_handle &gt;( ch ) acutally returns the container by value, o=
rtogonalny to the f</font>act if we have &amp;&amp; overloads and the solut=
ions presented by me will actually fix the code. Because the <font face=3D"=
Courier">* std::forward&lt; container_handle &gt;( ch )</font> will be crea=
ted and used in one expression. The auto&amp;&amp; will create dangling ref=
erence.<br><br>W dniu pi=C4=85tek, 11 lipca 2014 11:49:09 UTC+2 u=C5=BCytko=
wnik toma...@gmail.com napisa=C5=82:<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>Acutall case does even need susbtitute:<br><div=
><font face=3D"Courier">template&lt; typename container_handle &gt;</font><=
/div><div><font face=3D"Courier">void operate_on_fifth_thing( container_han=
dle &amp;&amp; ch ) {</font></div><div><font face=3D"Courier">&nbsp; proces=
s_for_a_long_time( </font><font face=3D"Courier"><font face=3D"Courier">* s=
td::forward&lt; container_handle &gt;( ch ) )[ 5 ]</font> );<br></font></di=
v><div><font face=3D"Courier">}</font></div><br>That willl work with any bo=
dy:<br>template&lt;typename T, typename F&gt;<br>void with(T&amp;&amp; t, F=
V&amp;&amp; fv) { std::forward&lt;FV&gt;(fv)(std::<wbr>forward&lt;T&gt;(t))=
; }<br><br><div><font face=3D"Courier">template&lt; typename container_hand=
le &gt;</font></div><div><font face=3D"Courier">void operate_on_fifth_thing=
( container_handle &amp;&amp; ch ) {<br>&nbsp;&nbsp;&nbsp; with(</font><fon=
t face=3D"Courier">( * std::forward&lt; container_handle &gt;( ch ) )[ 5 ],=
 [](</font><font face=3D"Courier">auto &amp;&amp; fifth_thing) {<br></font>=
</div></div><div><font face=3D"Courier"></font></div><div><font face=3D"Cou=
rier">&nbsp; &nbsp; &nbsp; // This is illustrated as a function call, but t=
here might as well be a loop here.</font></div><div><font face=3D"Courier">=
&nbsp; &nbsp; &nbsp; process_for_a_long_time( std::forward&lt; decltype( th=
ing ) &gt;( fifth_thing ) );<br>&nbsp;&nbsp;&nbsp; });<br></font></div><div=
><font face=3D"Courier">}</font></div></div></blockquote></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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_154_13869155.1405072585090--

.

--Apple-Mail=_8CD743D6-6E3C-4E9C-9C86-6382116E908B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1


On 2014-07-11, at 5:56 PM, tomaszkam@gmail.com wrote:

> And the really funny think. Your code will not work if container_handle i=
s a lazy evaluator and * std::forward< container_handle >( ch ) acutally re=
turns the container by value, ortogonalny to the fact if we have && overloa=
ds and the solutions presented by me will actually fix the code. Because th=
e * std::forward< container_handle >( ch ) will be created and used in one =
expression. The auto&& will create dangling reference.

operator[]() && is also assumed to return a prvalue. This is what gets boun=
d to the reference, so it does not dangle.

Factoring into a second one-line function completely misses the point. Some=
times we want multiple lines in a function ;v) .

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

--Apple-Mail=_8CD743D6-6E3C-4E9C-9C86-6382116E908B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014&=
ndash;07&ndash;11, at 5:56 PM, <a href=3D"mailto:tomaszkam@gmail.com">tomas=
zkam@gmail.com</a> wrote:</div><br class=3D"Apple-interchange-newline"><blo=
ckquote type=3D"cite"><div dir=3D"ltr">And the really funny think. Your cod=
e will not work if container_handle is a lazy evaluator and <font face=3D"C=
ourier">* std::forward&lt; container_handle &gt;( ch ) acutally returns the=
 container by value, ortogonalny to the f</font>act if we have &amp;&amp; o=
verloads and the solutions presented by me will actually fix the code. Beca=
use the <font face=3D"Courier">* std::forward&lt; container_handle &gt;( ch=
 )</font> will be created and used in one expression. The auto&amp;&amp; wi=
ll create dangling reference.<br></div></blockquote><div><br></div><div><fo=
nt face=3D"Courier">operator[]() &amp;&amp;</font>&nbsp;is also assumed to =
return a prvalue. This is what gets bound to the reference, so it does not =
dangle.</div><div><br></div><div>Factoring into a second one-line function =
completely misses the point. Sometimes we want multiple lines in a function=
 ;v) .</div></div><br></body></html>

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

--Apple-Mail=_8CD743D6-6E3C-4E9C-9C86-6382116E908B--

.

--Apple-Mail=_206A06F3-E0CE-407B-B5C7-CD2D5E009A6A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1


On 2014-07-11, at 5:47 PM, Ville Voutilainen <ville.voutilainen@gmail.com> =
wrote:

> On 11 July 2014 12:36, David Krauss <potswa@gmail.com> wrote:
>>=20
>> On 2014-07-11, at 5:34 PM, Ville Voutilainen <ville.voutilainen@gmail.co=
m> wrote:
>>=20
>>> Why is that code using auto&&?
>>=20
>> Can you rewrite it with any other substitute?
>=20
>=20
> That would depend on the answer to the question. The container is not
> going out of scope,

The pattern I intended to illustrate is, "take a one-liner using std::forwa=
rd and divide it over two lines by adding a named variable." If I'd passed =
ch to a function, it could well get moved-from.

A more straightforward example is simply naming the result of a generic fun=
ction.

auto && result =3D q( std::forward< V >( v ) );

Using auto instead of auto && may produce an unnecessary copy. No, it doesn=
't work if q returns an expiring reference, but yes, it does if q guarantee=
s it won't. It's possible, and good, to write libraries that don't have exp=
iring return values, regardless of what someone else did and the pain felt =
by their users.

Indeed, the question could go either way. Both alternatives introduce probl=
ems, which anyway may be worked around. I could create a generic function s=
ave_xvalue() to catch such and copy into a prvalue, and use that as an adap=
tor to auto &&. However, I think component-forwarding should get stuck with=
 the workaround because it's more esoteric than auto &&.

> I see nothing new that would be convincing to change the understanding
> I have about what
> we should do for the rvalue-ref-qualified observer overloads of optional.

Well, at least we see eye-to-eye. I hope you're right about the TS not carr=
ying a lock-in effect. The only responsible way to resolve this dilemma for=
 the entire library is with thorough review in a proper context.

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

--Apple-Mail=_206A06F3-E0CE-407B-B5C7-CD2D5E009A6A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014&=
ndash;07&ndash;11, at 5:47 PM, Ville Voutilainen &lt;<a href=3D"mailto:vill=
e.voutilainen@gmail.com">ville.voutilainen@gmail.com</a>&gt; wrote:</div><b=
r class=3D"Apple-interchange-newline"><blockquote type=3D"cite">On 11 July =
2014 12:36, David Krauss &lt;<a href=3D"mailto:potswa@gmail.com">potswa@gma=
il.com</a>&gt; wrote:<br><blockquote type=3D"cite"><br>On 2014-07-11, at 5:=
34 PM, Ville Voutilainen &lt;<a href=3D"mailto:ville.voutilainen@gmail.com"=
>ville.voutilainen@gmail.com</a>&gt; wrote:<br><br><blockquote type=3D"cite=
">Why is that code using auto&amp;&amp;?<br></blockquote><br>Can you rewrit=
e it with any other substitute?<br></blockquote><br><br>That would depend o=
n the answer to the question. The container is not<br>going out of scope,<b=
r></blockquote><div><br></div><div>The pattern I intended to illustrate is,=
 &ldquo;take a one-liner using std::forward and divide it over two lines by=
 adding a named variable.&rdquo; If I&rsquo;d passed <font face=3D"Courier"=
>ch</font> to a function, it could well get moved-from.</div><div><br></div=
><div>A more straightforward example is simply naming the result of a gener=
ic function.</div><div><br></div><div><font face=3D"Courier">auto &amp;&amp=
; result =3D q( std::forward&lt; V &gt;( v ) );</font></div><div><br></div>=
<div>Using&nbsp;<font face=3D"Courier">auto</font> instead of <font face=3D=
"Courier">auto &amp;&amp;</font>&nbsp;may produce an unnecessary copy. No, =
it doesn&rsquo;t work if q returns an expiring reference, but yes, it does =
if q guarantees it won&rsquo;t. It&rsquo;s possible, and good, to write lib=
raries that don&rsquo;t have expiring return values, regardless of what som=
eone else did and the pain felt by their users.</div><div><br></div><div>In=
deed, the question could go either way. Both alternatives introduce problem=
s, which anyway may be worked around. I could create a generic function <fo=
nt face=3D"Courier">save_xvalue()</font>&nbsp;to catch such and copy into a=
 prvalue, and use that as an adaptor to <font face=3D"Courier">auto &amp;&a=
mp;</font>. However, I think component-forwarding should get stuck with the=
 workaround because it&rsquo;s more esoteric than <font face=3D"Courier">au=
to &amp;&amp;</font>.</div><br><blockquote type=3D"cite">I see nothing new =
that would be convincing to change the understanding<br>I have about what<b=
r>we should do for the rvalue-ref-qualified observer overloads of optional.=
<br></blockquote></div><br><div>Well, at least we see eye-to-eye. I hope yo=
u&rsquo;re right about the TS not carrying a lock-in effect. The only respo=
nsible way to resolve this dilemma for the entire library is with thorough =
review in a proper context.</div><div><br></div></body></html>

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

--Apple-Mail=_206A06F3-E0CE-407B-B5C7-CD2D5E009A6A--

.

------=_Part_178_3937797.1405074322161
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



W dniu pi=C4=85tek, 11 lipca 2014 12:17:51 UTC+2 u=C5=BCytkownik David Krau=
ss napisa=C5=82:
>
>
> On 2014=E2=80=9307=E2=80=9311, at 5:56 PM, toma...@gmail.com <javascript:=
> wrote:
>
> And the really funny think. Your code will not work if container_handle i=
s=20
> a lazy evaluator and * std::forward< container_handle >( ch ) acutally=20
> returns the container by value, ortogonalny to the fact if we have &&=20
> overloads and the solutions presented by me will actually fix the code.=
=20
> Because the * std::forward< container_handle >( ch ) will be created and=
=20
> used in one expression. The auto&& will create dangling reference.
>
>
> operator[]() && is also assumed to return a prvalue. This is what gets=20
> bound to the reference, so it does not dangle.
>

But it current design is current state (without && qualifiers) in not work.=
=20
And having && returning by value cause a lot of other problmes (see post=20
above) - especially copying in place wher is is not actually needed. The=20
auto&& f, will still not work if *ch[0] will use an expression template and=
=20
return some operator_result by prvalue that has reference to ch. So if we=
=20
cannot make the auto&& to work in generic code (the generic code should=20
handle expression template), there is no reason to introduce prvalue &&=20
overloads, especially when...

>
> Factoring into a second one-line function completely misses the point.=20
> Sometimes we want multiple lines in a function ;v) .
>
>
... we can use wiht(expr, [](auto&& ) { arbitrally code; }) to make this=20
work everwhere. And yes we can put more than one line in lambda.

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

<div dir=3D"ltr"><br><br>W dniu pi=C4=85tek, 11 lipca 2014 12:17:51 UTC+2 u=
=C5=BCytkownik David Krauss napisa=C5=82:<blockquote class=3D"gmail_quote" =
style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-l=
eft: 1ex;"><div style=3D"word-wrap:break-word"><br><div><div>On 2014=E2=80=
=9307=E2=80=9311, at 5:56 PM, <a href=3D"javascript:" target=3D"_blank" gdf=
-obfuscated-mailto=3D"MAw6D2O61Z8J" onmousedown=3D"this.href=3D'javascript:=
';return true;" onclick=3D"this.href=3D'javascript:';return true;">toma...@=
gmail.com</a> wrote:</div><br><blockquote type=3D"cite"><div dir=3D"ltr">An=
d the really funny think. Your code will not work if container_handle is a =
lazy evaluator and <font face=3D"Courier">* std::forward&lt; container_hand=
le &gt;( ch ) acutally returns the container by value, ortogonalny to the f=
</font>act if we have &amp;&amp; overloads and the solutions presented by m=
e will actually fix the code. Because the <font face=3D"Courier">* std::for=
ward&lt; container_handle &gt;( ch )</font> will be created and used in one=
 expression. The auto&amp;&amp; will create dangling reference.<br></div></=
blockquote><div><br></div><div><font face=3D"Courier">operator[]() &amp;&am=
p;</font>&nbsp;is also assumed to return a prvalue. This is what gets bound=
 to the reference, so it does not dangle.</div></div></div></blockquote><di=
v><br>But it current design is current state (without &amp;&amp; qualifiers=
) in not work. And having &amp;&amp; returning by value cause a lot of othe=
r problmes (see post above) - especially copying in place wher is is not ac=
tually needed. The auto&amp;&amp; f, will still not work if *ch[0] will use=
 an expression template and return some operator_result by prvalue that has=
 reference to ch. So if we cannot make the auto&amp;&amp; to work in generi=
c code (the generic code should handle expression template), there is no re=
ason to introduce prvalue &amp;&amp; overloads, especially when...<br></div=
><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bo=
rder-left: 1px #ccc solid;padding-left: 1ex;"><div style=3D"word-wrap:break=
-word"><div><div><br></div><div>Factoring into a second one-line function c=
ompletely misses the point. Sometimes we want multiple lines in a function =
;v) .</div></div><br></div></blockquote><div><br>.. we can use wiht(expr, [=
](auto&amp;&amp; ) { arbitrally code; }) to make this work everwhere. And y=
es we can put more than one line in lambda.<br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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_178_3937797.1405074322161--

.

On Fri, Jul 11, 2014 at 12:21 PM, David Krauss <potswa@gmail.com> wrote:
> Using auto instead of auto && may produce an unnecessary copy. No, it

So the problem is basically the auto&&? You're looking for something
that won't deduce to a xvalue..

--

---
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_186_14137299.1405074596413
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



W dniu pi=C4=85tek, 11 lipca 2014 12:21:28 UTC+2 u=C5=BCytkownik David Krau=
ss napisa=C5=82:
>
>
> On 2014=E2=80=9307=E2=80=9311, at 5:47 PM, Ville Voutilainen <ville.vo...=
@gmail.com=20
> <javascript:>> wrote:
>
> On 11 July 2014 12:36, David Krauss <pot...@gmail.com <javascript:>>=20
> wrote:
>
>
> On 2014-07-11, at 5:34 PM, Ville Voutilainen <ville.vo...@gmail.com=20
> <javascript:>> wrote:
>
> Why is that code using auto&&?
>
>
> Can you rewrite it with any other substitute?
>
>
>
> That would depend on the answer to the question. The container is not
> going out of scope,
>
>
> The pattern I intended to illustrate is, =E2=80=9Ctake a one-liner using=
=20
> std::forward and divide it over two lines by adding a named variable.=E2=
=80=9D If=20
> I=E2=80=99d passed ch to a function, it could well get moved-from.
>
And I have actually put a solution a pattern for this problems that does=20
not create dangling reference in any case:
Change
  f(g())
To:
  auto r1 =3D []() -> decltype(auto) { return g(); };
  g(r1());=20


> A more straightforward example is simply naming the result of a generic=
=20
> function.
>
> auto && result =3D q( std::forward< V >( v ) );
>
> Using auto instead of auto && may produce an unnecessary copy. No, it=20
> doesn=E2=80=99t work if q returns an expiring reference, but yes, it does=
 if q=20
> guarantees it won=E2=80=99t. It=E2=80=99s possible, and good, to write li=
braries that don=E2=80=99t=20
> have expiring return values, regardless of what someone else did and the=
=20
> pain felt by their users.
>
> Indeed, the question could go either way. Both alternatives introduce=20
> problems, which anyway may be worked around. I could create a generic=20
> function save_xvalue() to catch such and copy into a prvalue, and use=20
> that as an adaptor to auto &&. However, I think component-forwarding=20
> should get stuck with the workaround because it=E2=80=99s more esoteric t=
han auto=20
> &&.
>
> I see nothing new that would be convincing to change the understanding
> I have about what
> we should do for the rvalue-ref-qualified observer overloads of optional.
>
>
> Well, at least we see eye-to-eye. I hope you=E2=80=99re right about the T=
S not=20
> carrying a lock-in effect. The only responsible way to resolve this dilem=
ma=20
> for the entire library is with thorough review in a proper context.
>
>

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

<div dir=3D"ltr"><br><br>W dniu pi=C4=85tek, 11 lipca 2014 12:21:28 UTC+2 u=
=C5=BCytkownik David Krauss napisa=C5=82:<blockquote class=3D"gmail_quote" =
style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-l=
eft: 1ex;"><div style=3D"word-wrap:break-word"><br><div><div>On 2014=E2=80=
=9307=E2=80=9311, at 5:47 PM, Ville Voutilainen &lt;<a href=3D"javascript:"=
 target=3D"_blank" gdf-obfuscated-mailto=3D"XZzhSdpt2JEJ" onmousedown=3D"th=
is.href=3D'javascript:';return true;" onclick=3D"this.href=3D'javascript:';=
return true;">ville.vo...@gmail.com</a>&gt; wrote:</div><br><blockquote typ=
e=3D"cite">On 11 July 2014 12:36, David Krauss &lt;<a href=3D"javascript:" =
target=3D"_blank" gdf-obfuscated-mailto=3D"XZzhSdpt2JEJ" onmousedown=3D"thi=
s.href=3D'javascript:';return true;" onclick=3D"this.href=3D'javascript:';r=
eturn true;">pot...@gmail.com</a>&gt; wrote:<br><blockquote type=3D"cite"><=
br>On 2014-07-11, at 5:34 PM, Ville Voutilainen &lt;<a href=3D"javascript:"=
 target=3D"_blank" gdf-obfuscated-mailto=3D"XZzhSdpt2JEJ" onmousedown=3D"th=
is.href=3D'javascript:';return true;" onclick=3D"this.href=3D'javascript:';=
return true;">ville.vo...@gmail.com</a>&gt; wrote:<br><br><blockquote type=
=3D"cite">Why is that code using auto&amp;&amp;?<br></blockquote><br>Can yo=
u rewrite it with any other substitute?<br></blockquote><br><br>That would =
depend on the answer to the question. The container is not<br>going out of =
scope,<br></blockquote><div><br></div><div>The pattern I intended to illust=
rate is, =E2=80=9Ctake a one-liner using std::forward and divide it over tw=
o lines by adding a named variable.=E2=80=9D If I=E2=80=99d passed <font fa=
ce=3D"Courier">ch</font> to a function, it could well get moved-from.</div>=
</div></div></blockquote><div>And I have actually put a solution a pattern =
for this problems that does not create dangling reference in any case:<br>C=
hange<br>&nbsp; f(g())<br>To:<br>&nbsp; auto r1 =3D []() -&gt; decltype(aut=
o) { return g(); };<br>&nbsp; g(r1()); <br><br></div><blockquote class=3D"g=
mail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc sol=
id;padding-left: 1ex;"><div style=3D"word-wrap:break-word"><div><div><br></=
div><div>A more straightforward example is simply naming the result of a ge=
neric function.</div><div><br></div><div><font face=3D"Courier">auto &amp;&=
amp; result =3D q( std::forward&lt; V &gt;( v ) );</font></div><div><br></d=
iv><div>Using&nbsp;<font face=3D"Courier">auto</font> instead of <font face=
=3D"Courier">auto &amp;&amp;</font>&nbsp;may produce an unnecessary copy. N=
o, it doesn=E2=80=99t work if q returns an expiring reference, but yes, it =
does if q guarantees it won=E2=80=99t. It=E2=80=99s possible, and good, to =
write libraries that don=E2=80=99t have expiring return values, regardless =
of what someone else did and the pain felt by their users.</div><div><br></=
div><div>Indeed, the question could go either way. Both alternatives introd=
uce problems, which anyway may be worked around. I could create a generic f=
unction <font face=3D"Courier">save_xvalue()</font>&nbsp;to catch such and =
copy into a prvalue, and use that as an adaptor to <font face=3D"Courier">a=
uto &amp;&amp;</font>. However, I think component-forwarding should get stu=
ck with the workaround because it=E2=80=99s more esoteric than <font face=
=3D"Courier">auto &amp;&amp;</font>.</div><br><blockquote type=3D"cite">I s=
ee nothing new that would be convincing to change the understanding<br>I ha=
ve about what<br>we should do for the rvalue-ref-qualified observer overloa=
ds of optional.<br></blockquote></div><br><div>Well, at least we see eye-to=
-eye. I hope you=E2=80=99re right about the TS not carrying a lock-in effec=
t. The only responsible way to resolve this dilemma for the entire library =
is with thorough review in a proper context.</div><div><br></div></div></bl=
ockquote></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_186_14137299.1405074596413--

.

On 2014-07-11, at 6:29 PM, Olaf van der Spek <olafvdspek@gmail.com> wrote:

> On Fri, Jul 11, 2014 at 12:21 PM, David Krauss <potswa@gmail.com> wrote:
>> Using auto instead of auto && may produce an unnecessary copy. No, it
>
> So the problem is basically the auto&&? You're looking for something
> that won't deduce to a xvalue..

Categories aren't deduced, types are. An named auto && is not an xvalue.

--

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

.

On 11 July 2014 13:21, David Krauss <potswa@gmail.com> wrote:
> Well, at least we see eye-to-eye. I hope you=E2=80=99re right about the T=
S not
> carrying a lock-in effect. The only responsible way to resolve this dilem=
ma
> for the entire library is with thorough review in a proper context.


I think we are more or less in agreement that a situation where
rvalue-ref-qualified
functions, if any, return either T&& all-over-the-place or T
all-over-the-place is not
very good; there are very reasonable uses for both, and it would be decent
to provide both choices somehow. With the current trend, where no other lib=
rary
facility chooses safety-for-auto&&-locals, and all of them go for performan=
ce,
optional fits into the picture better if it chooses performance over
safety-for-auto&&-locals.

Solving the dilemma library-wide would indeed require a thorough
review, but that's
something that should be dealt with when/if a new version of the
standard library emerges.
There's been some talk about that, incl. specifying a conceptified and
potentially
range-supporting library, but as things stand, the Fundamentals v1
needs to fit in
the larger picture of the existing library, as far as possible.

Just my 0.02 euros, of course.

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

.

On Fri, Jul 11, 2014 at 12:31 PM, David Krauss <potswa@gmail.com> wrote:
>> So the problem is basically the auto&&? You're looking for something
>> that won't deduce to a xvalue..
>
> Categories aren't deduced, types are. An named auto && is not an xvalue.

But the problem is still the auto&& isn't it? You're looking for
something that'll copy instead of becoming a dangling reference.

--
Olaf

--

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

.

On 2014-07-11, at 6:33 PM, Olaf van der Spek <olafvdspek@gmail.com> wrote:

> On Fri, Jul 11, 2014 at 12:31 PM, David Krauss <potswa@gmail.com> wrote:
>>> So the problem is basically the auto&&? You're looking for something
>>> that won't deduce to a xvalue..
>>=20
>> Categories aren't deduced, types are. An named auto && is not an xvalue.

I meant, named T &&.

> But the problem is still the auto&& isn't it? You're looking for
> something that'll copy instead of becoming a dangling reference.


Yes, the problem is dangling references. I think they're an avoidable libra=
ry design choice, and they don't add fundamental capability. If you know th=
at an xvalue would be safe, and you can obtain an lvalue reference, then yo=
u can convert the xvalue to an lvalue. The metaprogramming behind that tran=
sfer is the big question.

But, I've said my peace as for this thread, and I hope the discussion can c=
ontinue with proper papers, etc.

--=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_199_12578268.1405075084591
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



W dniu pi=C4=85tek, 11 lipca 2014 12:32:53 UTC+2 u=C5=BCytkownik Ville Vout=
ilainen=20
napisa=C5=82:
>
> On 11 July 2014 13:21, David Krauss <pot...@gmail.com <javascript:>>=20
> wrote:=20
> > Well, at least we see eye-to-eye. I hope you=E2=80=99re right about the=
 TS not=20
> > carrying a lock-in effect. The only responsible way to resolve this=20
> dilemma=20
> > for the entire library is with thorough review in a proper context.=20
>
>
> I think we are more or less in agreement that a situation where=20
> rvalue-ref-qualified=20
> functions, if any, return either T&& all-over-the-place or T=20
> all-over-the-place is not=20
> very good; there are very reasonable uses for both, and it would be decen=
t=20
> to provide both choices somehow. With the current trend, where no other=
=20
> library=20
> facility chooses safety-for-auto&&-locals, and all of them go for=20
> performance,=20
> optional fits into the picture better if it chooses performance over=20
> safety-for-auto&&-locals.=20
>
> But I trying to point that safety-for-auto&&-locals is not reallly=20
achiveable.
Please remember the consequences of making auto&& s =3D f().m works
or that we have expression templates and they won't be gone.

And I thinl that "auto&&" was promotted to being silver-bullet for
generic programing, when it actually cannot be.

=20

> Solving the dilemma library-wide would indeed require a thorough=20
> review, but that's=20
> something that should be dealt with when/if a new version of the=20
> standard library emerges.=20
> There's been some talk about that, incl. specifying a conceptified and=20
> potentially=20
> range-supporting library, but as things stand, the Fundamentals v1=20
> needs to fit in=20
> the larger picture of the existing library, as far as possible.=20
>
> Just my 0.02 euros, of course.=20
>

--=20

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

------=_Part_199_12578268.1405075084591
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>W dniu pi=C4=85tek, 11 lipca 2014 12:32:53 UTC+2 u=
=C5=BCytkownik Ville Voutilainen napisa=C5=82:<blockquote class=3D"gmail_qu=
ote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padd=
ing-left: 1ex;">On 11 July 2014 13:21, David Krauss &lt;<a href=3D"javascri=
pt:" target=3D"_blank" gdf-obfuscated-mailto=3D"pybleKNk47YJ" onmousedown=
=3D"this.href=3D'javascript:';return true;" onclick=3D"this.href=3D'javascr=
ipt:';return true;">pot...@gmail.com</a>&gt; wrote:
<br>&gt; Well, at least we see eye-to-eye. I hope you=E2=80=99re right abou=
t the TS not
<br>&gt; carrying a lock-in effect. The only responsible way to resolve thi=
s dilemma
<br>&gt; for the entire library is with thorough review in a proper context=
..
<br>
<br>
<br>I think we are more or less in agreement that a situation where
<br>rvalue-ref-qualified
<br>functions, if any, return either T&amp;&amp; all-over-the-place or T
<br>all-over-the-place is not
<br>very good; there are very reasonable uses for both, and it would be dec=
ent
<br>to provide both choices somehow. With the current trend, where no other=
 library
<br>facility chooses safety-for-auto&amp;&amp;-locals, and all of them go f=
or performance,
<br>optional fits into the picture better if it chooses performance over
<br>safety-for-auto&amp;&amp;-locals.
<br>
<br></blockquote><div>But I trying to point that safety-for-auto&amp;&amp;-=
locals is not reallly achiveable.<br>Please remember the consequences of ma=
king auto&amp;&amp; s =3D f().m works<br>or that we have expression templat=
es and they won't be gone.<br><br>And I thinl that "auto&amp;&amp;" was pro=
motted to being silver-bullet for<br>generic programing, when it actually c=
annot be.<br><br>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"mar=
gin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">S=
olving the dilemma library-wide would indeed require a thorough
<br>review, but that's
<br>something that should be dealt with when/if a new version of the
<br>standard library emerges.
<br>There's been some talk about that, incl. specifying a conceptified and
<br>potentially
<br>range-supporting library, but as things stand, the Fundamentals v1
<br>needs to fit in
<br>the larger picture of the existing library, as far as possible.
<br>
<br>Just my 0.02 euros, of course.
<br></blockquote></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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_199_12578268.1405075084591--

.

On 2014-07-11, at 6:37 PM, David Krauss <potswa@gmail.com> wrote:

> you can convert the xvalue to an lvalue

Other way around, of course.

--

---
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_176_5463280.1405076240252
Content-Type: text/plain; charset=UTF-8

Do we found any other argumentation for T member()&& overload except making
auto&& s = f; work for some cases?

In the follwoing example:
  template<typename T>
  delctype(auto) f(T&& t) { return std::addressof(*std::forward<T>(t)); }

  template<typename T>
  delctype(auto) g(T&& t) {
      auto&& ret = f(std::forward<T>(t));
      //will create a dangling pointer, because the liftetime of result of
f.value() is not longer same a liftme of the owner t
   }
The making auto&& works actually breaks the auto&&. Do we really wont to
make "auto&&" to work at some cases
in the cost of breaking other cases?

--

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

<div dir=3D"ltr">Do we found any other argumentation for T member()&amp;&am=
p; overload except making auto&amp;&amp; s =3D f; work for some cases? <br>=
<br>In the follwoing example:<br>&nbsp; template&lt;typename T&gt;<br>&nbsp=
; delctype(auto) f(T&amp;&amp; t) { return std::addressof(*std::forward&lt;=
T&gt;(t)); }<br>&nbsp;&nbsp; <br>&nbsp; template&lt;typename T&gt;<br>&nbsp=
; delctype(auto) g(T&amp;&amp; t) { <br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; auto=
&amp;&amp; ret =3D f(std::forward&lt;T&gt;(t)); <br>&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp; //will create a dangling pointer, because the liftetime of result o=
f f.value() is not longer same a liftme of the owner t<br>&nbsp;&nbsp; }<br=
>The making auto&amp;&amp; works actually breaks the auto&amp;&amp;. Do we =
really wont to make "auto&amp;&amp;" to work at some cases<br>in the cost o=
f breaking other cases? <br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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_176_5463280.1405076240252--

.

--Apple-Mail=_1F73ABED-AE92-4FD5-999C-76FF7336FE37
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1


On 2014-07-11, at 6:57 PM, tomaszkam@gmail.com wrote:

> Do we found any other argumentation for T member()&& overload except maki=
ng auto&& s =3D f; work for some cases?=20
>=20
> In the follwoing example:
>   template<typename T>
>   delctype(auto) f(T&& t) { return std::addressof(*std::forward<T>(t)); }
>   =20
>   template<typename T>
>   delctype(auto) g(T&& t) {=20
>       auto&& ret =3D f(std::forward<T>(t));=20
>       //will create a dangling pointer, because the liftetime of result o=
f f.value() is not longer same a liftme of the owner t

Once again you've omitted the parens after f in the comment. Please proofre=
ad before posting. f is a naked function and f() is a naked pointer. Neithe=
r can have a member .value. You probably mean *f or f->value() under the as=
sumption that f is type optional*.

A function that converts a possibly-owning smart pointer to merely an obser=
ving naked pointer is obviously not a candidate for move semantics, so the =
example is not reasonable.

I will provide a thorough analysis of value categories, member access expre=
ssions, forwarding contexts, and function calls (or even better, someone el=
se will), but this thread is not the right place.

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

--Apple-Mail=_1F73ABED-AE92-4FD5-999C-76FF7336FE37
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014&=
ndash;07&ndash;11, at 6:57 PM, <a href=3D"mailto:tomaszkam@gmail.com">tomas=
zkam@gmail.com</a> wrote:</div><br class=3D"Apple-interchange-newline"><blo=
ckquote type=3D"cite"><div dir=3D"ltr">Do we found any other argumentation =
for T member()&amp;&amp; overload except making auto&amp;&amp; s =3D f; wor=
k for some cases? <br><br>In the follwoing example:<br>&nbsp; template&lt;t=
ypename T&gt;<br>&nbsp; delctype(auto) f(T&amp;&amp; t) { return std::addre=
ssof(*std::forward&lt;T&gt;(t)); }<br>&nbsp;&nbsp; <br>&nbsp; template&lt;t=
ypename T&gt;<br>&nbsp; delctype(auto) g(T&amp;&amp; t) { <br>&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp; auto&amp;&amp; ret =3D f(std::forward&lt;T&gt;(t)); <br>&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp; //will create a dangling pointer, because the=
 liftetime of result of f.value() is not longer same a liftme of the owner =
t<br></div></blockquote><div><br></div><div>Once again you&rsquo;ve omitted=
 the parens after f in the comment. Please proofread before posting. f is a=
 naked function and f() is a naked pointer. Neither can have a member <font=
 face=3D"Courier">.value</font>. You probably mean <font face=3D"Courier">*=
f</font> or <font face=3D"Courier">f-&gt;value()</font> under the assumptio=
n that f is type <font face=3D"Courier">optional*</font>.</div><div><br></d=
iv><div>A function that converts a possibly-owning smart pointer to merely =
an observing naked pointer is obviously not a candidate for move semantics,=
 so the example is not reasonable.</div><div><br></div><div>I will provide =
a thorough analysis of value categories, member access expressions, forward=
ing contexts, and function calls (or even better, someone else will), but t=
his thread is not the right place.</div><div><br></div></div></body></html>

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

--Apple-Mail=_1F73ABED-AE92-4FD5-999C-76FF7336FE37--

.

------=_Part_331_5533592.1405150049235
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



W dniu sobota, 12 lipca 2014 01:30:24 UTC+2 u=C5=BCytkownik David Krauss na=
pisa=C5=82:
>
>
> On 2014=E2=80=9307=E2=80=9311, at 6:57 PM, toma...@gmail.com <javascript:=
> wrote:
>
> Do we found any other argumentation for T member()&& overload except=20
> making auto&& s =3D f; work for some cases?=20
>
> In the follwoing example:
>   template<typename T>
>   delctype(auto) f(T&& t) { return std::addressof(*std::forward<T>(t)); }
>   =20
>   template<typename T>
>   delctype(auto) g(T&& t) {=20
>       auto&& ret =3D f(std::forward<T>(t));=20
>       //will create a dangling pointer, because the liftetime of result o=
f=20
> f.value() is not longer same a liftme of the owner t
>
>
> Once again you=E2=80=99ve omitted the parens after f in the comment. Plea=
se=20
> proofread before posting. f is a naked function and f() is a naked pointe=
r.=20
> Neither can have a member .value. You probably mean *f or f->value()=20
> under the assumption that f is type optional*.
>
>
I agree with you, in the way the post was written I failed to present my=20
point. Sorry for that.
=20

> A function that converts a possibly-owning smart pointer to merely an=20
> observing naked pointer is obviously not a candidate for move semantics, =
so=20
> the example is not reasonable.
>
>
Let me present my last point again, because I think it was never presented=
=20
in the thread.

I will begin with describing the issue: Having prvalue overloads (T=20
operator*()) for optional<T> breaks the connection between expression of=20
type optional (opt_expr) and the lifetime of bounded result of=20
(opt_expr.value()) bound to the reference.
This will only happen of opt_expr is rvalue, so the only situation when it=
=20
may happen by accident is the generic context.

Example:
template<typename Nullable>
void do_something(Nullable&& nullable)
{
  pointer_type_t<Nullable> pointer =3D nullptr;
  if (nullable)
  {
     auto&& value =3D *std::forward<Nullable>(nullable);
     //Do something with value
     pointer =3D addressof(value);
  }
  function_taking_pointer(pointer);
}
1.The above code works if the passed Nullable types does not define any=20
rvalue overloads for operator* - current status quo with library.=20
   Because the lifetime of object bound by auto&& value =3D=20
*std::forward<Nullable>(nullable); is always bound to the lifetime of=20
nullable.
2. The above code work if the passed Nullable type define && overload of=20
operator* that returns by rvalue-reference. Same reasoning apply as above.
3. The above code does not work if if the passed Nullable type define &&=20
overload of operator* that returns by value.
    Lifetime of object bound by auto&& value =3D=20
*std::forward<Nullable>(nullable); is not the same as lifetime of nullable.

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

<div dir=3D"ltr"><br><br>W dniu sobota, 12 lipca 2014 01:30:24 UTC+2 u=C5=
=BCytkownik David Krauss napisa=C5=82:<blockquote class=3D"gmail_quote" sty=
le=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left=
: 1ex;"><div style=3D"word-wrap:break-word"><br><div><div>On 2014=E2=80=930=
7=E2=80=9311, at 6:57 PM, <a href=3D"javascript:" target=3D"_blank" gdf-obf=
uscated-mailto=3D"tIDmZFmCIScJ" onmousedown=3D"this.href=3D'javascript:';re=
turn true;" onclick=3D"this.href=3D'javascript:';return true;">toma...@gmai=
l.com</a> wrote:</div><br><blockquote type=3D"cite"><div dir=3D"ltr">Do we =
found any other argumentation for T member()&amp;&amp; overload except maki=
ng auto&amp;&amp; s =3D f; work for some cases? <br><br>In the follwoing ex=
ample:<br>&nbsp; template&lt;typename T&gt;<br>&nbsp; delctype(auto) f(T&am=
p;&amp; t) { return std::addressof(*std::forward&lt;<wbr>T&gt;(t)); }<br>&n=
bsp;&nbsp; <br>&nbsp; template&lt;typename T&gt;<br>&nbsp; delctype(auto) g=
(T&amp;&amp; t) { <br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; auto&amp;&amp; ret =3D=
 f(std::forward&lt;T&gt;(t)); <br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; //will cre=
ate a dangling pointer, because the liftetime of result of f.value() is not=
 longer same a liftme of the owner t<br></div></blockquote><div><br></div><=
div>Once again you=E2=80=99ve omitted the parens after f in the comment. Pl=
ease proofread before posting. f is a naked function and f() is a naked poi=
nter. Neither can have a member <font face=3D"Courier">.value</font>. You p=
robably mean <font face=3D"Courier">*f</font> or <font face=3D"Courier">f-&=
gt;value()</font> under the assumption that f is type <font face=3D"Courier=
">optional*</font>.</div><div><br></div></div></div></blockquote><div><br>I=
 agree with you, in the way the post was written I failed to present my poi=
nt. Sorry for that.<br>&nbsp;</div><blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;"><div style=3D"word-wrap:break-word"><div><div></div><div>A function t=
hat converts a possibly-owning smart pointer to merely an observing naked p=
ointer is obviously not a candidate for move semantics, so the example is n=
ot reasonable.</div><br></div></div></blockquote><div><br>Let me present my=
 last point again, because I think it was never presented in the thread.<br=
><br>I will begin with describing the issue: Having prvalue overloads (T op=
erator*()) for optional&lt;T&gt; breaks the connection between expression o=
f type optional (opt_expr) and the lifetime of bounded result of (opt_expr.=
value()) bound to the reference.<br>This will only happen of opt_expr is rv=
alue, so the only situation when it may happen by accident is the generic c=
ontext.<br><br>Example:<br>template&lt;typename Nullable&gt;<br>void do_som=
ething(Nullable&amp;&amp; nullable)<br>{<br>&nbsp; pointer_type_t&lt;Nullab=
le&gt; pointer =3D nullptr;<br>&nbsp; if (nullable)<br>&nbsp; {<br>&nbsp;&n=
bsp;&nbsp;&nbsp; auto&amp;&amp; value =3D *std::forward&lt;Nullable&gt;(nul=
lable);<br>&nbsp;&nbsp;&nbsp;&nbsp; //Do something with value<br>&nbsp;&nbs=
p;&nbsp;&nbsp; pointer =3D addressof(value);<br>&nbsp; }<br>&nbsp; function=
_taking_pointer(pointer);<br>}<br>1.The above code works if the passed Null=
able types does not define any rvalue overloads for operator* - current sta=
tus quo with library. <br>&nbsp;&nbsp; Because the lifetime of object bound=
 by auto&amp;&amp; value =3D *std::forward&lt;Nullable&gt;(nullable); is al=
ways bound to the lifetime of nullable.<br>2. The above code work if the pa=
ssed Nullable type define &amp;&amp; overload of operator* that returns by =
rvalue-reference. Same reasoning apply as above.<br>3. The above code does =
not work if if the passed Nullable type define &amp;&amp; overload of opera=
tor* that returns by value.<br>&nbsp;&nbsp;&nbsp; Lifetime of object bound =
by auto&amp;&amp; value =3D *std::forward&lt;Nullable&gt;(nullable); is not=
 the same as lifetime of nullable.<br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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_331_5533592.1405150049235--

.

--Apple-Mail=_AB2BD471-1A28-40A3-B3E0-944E7AB57C56
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1


On 2014-07-12, at 3:27 PM, tomaszkam@gmail.com wrote:

> 3. The above code does not work if if the passed Nullable type define && =
overload of operator* that returns by value.
>     Lifetime of object bound by auto&& value =3D *std::forward<Nullable>(=
nullable); is not the same as lifetime of nullable.

Yes, but in that case what does the std::forward express? Reading that func=
tion, I would intuitively expect addressof(value) to become a dangling refe=
rence. Any other interpretation requires thinking hard about what did *not*=
 happen to the result of forward. It wasn't passed to a function, but absen=
ce of some common thing isn't a good discriminating factor. (And in fact, i=
t was passed to a function, operator *.)

Because function_taking_pointer(pointer) passes a non-owning observer, null=
able must live at least through that call. The intent is best expressed by =
simply value =3D * nullable; do not use forward(). This can be declared as =
auto && or auto & equivalently.

Am I missing something?

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

--Apple-Mail=_AB2BD471-1A28-40A3-B3E0-944E7AB57C56
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014&=
ndash;07&ndash;12, at 3:27 PM, <a href=3D"mailto:tomaszkam@gmail.com">tomas=
zkam@gmail.com</a> wrote:</div><br class=3D"Apple-interchange-newline"><blo=
ckquote type=3D"cite"><div dir=3D"ltr">3. The above code does not work if i=
f the passed Nullable type define &amp;&amp; overload of operator* that ret=
urns by value.<br><div>&nbsp;&nbsp;&nbsp; Lifetime of object bound by auto&=
amp;&amp; value =3D *std::forward&lt;Nullable&gt;(nullable); is not the sam=
e as lifetime of nullable.<br></div></div></blockquote><div><br></div></div=
>Yes, but in that case what does the <font face=3D"Courier">std::forward</f=
ont> express? Reading that function, I would intuitively expect <font face=
=3D"Courier">addressof(value)</font> to become a dangling reference. Any ot=
her interpretation requires thinking hard about what did *<i>not</i>* happe=
n to&nbsp;the result of <font face=3D"Courier">forward</font>. It wasn&rsqu=
o;t passed to a function, but absence of some common thing isn&rsquo;t a go=
od discriminating factor. (And in fact, it was passed to a function, <font =
face=3D"Courier">operator *</font>.)<div><br></div><div>Because&nbsp;<font =
face=3D"Courier">function_taking_pointer(pointer)</font>&nbsp;passes a non-=
owning observer, <font face=3D"Courier">nullable</font> must live at least =
through that call. The intent is best expressed by simply&nbsp;<font face=
=3D"Courier">value =3D * nullable</font>; do not use&nbsp;<font face=3D"Cou=
rier">forward()</font>. This can be declared as&nbsp;<font face=3D"Courier"=
>auto &amp;&amp;</font> or <font face=3D"Courier">auto &amp;</font> equival=
ently.</div><div><br></div><div>Am I missing something?</div><div><br></div=
></body></html>

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

--Apple-Mail=_AB2BD471-1A28-40A3-B3E0-944E7AB57C56--

.

------=_Part_543_20324844.1405156202697
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

W dniu sobota, 12 lipca 2014 09:51:15 UTC+2 u=C5=BCytkownik David Krauss na=
pisa=C5=82:
>
>
> On 2014=E2=80=9307=E2=80=9312, at 3:27 PM, toma...@gmail.com <javascript:=
> wrote:
>
> 3. The above code does not work if if the passed Nullable type define &&=
=20
> overload of operator* that returns by value.
>     Lifetime of object bound by auto&& value =3D=20
> *std::forward<Nullable>(nullable); is not the same as lifetime of nullabl=
e.
>
>
> Yes, but in that case what does the std::forward express? Reading that=20
> function, I would intuitively expect addressof(value) to become a=20
> dangling reference. Any other interpretation requires thinking hard about=
=20
> what did **not** happen to the result of forward. It wasn=E2=80=99t passe=
d to a=20
> function, but absence of some common thing isn=E2=80=99t a good discrimin=
ating=20
> factor. (And in fact, it was passed to a function, operator *.)
>
> Because function_taking_pointer(pointer) passes a non-owning observer,=20
> nullable must live at least through that call. The intent is best=20
> expressed by simply value =3D * nullable; do not use forward(). This can =
be=20
> declared as auto && or auto & equivalently.
>
> Am I missing something?
>

No, your are ok, But let me use your previous example.=20
template< typename container_handle >
void operate_on_fifth_thing( container_handle && ch ) {
    // Get only the fifth element. We don=E2=80=99t need the rest; OK to fr=
ee those=20
resources.
    // However, if not assuming ownership, there=E2=80=99s no need to make =
a copy.
    auto && fifth_thing =3D=3D ( * std::forward< container_handle >( ch ) )=
[ 5=20
];

    // This is illustrated as a function call, but there might as well be a=
=20
loop here.
    process_for_a_long_time( std::forward< decltype( thing ) >( fifth_thing=
=20
) );
}

Then assume than we want add some log information:
template< typename container_handle >
void operate_on_fifth_thing( container_handle && ch ) {
    // Get only the fifth element. We don=E2=80=99t need the rest; OK to fr=
ee those=20
resources.
    // However, if not assuming ownership, there=E2=80=99s no need to make =
a copy.
    auto && fifth_thing =3D=3D ( * std::forward< container_handle >( ch ) )=
[ 5=20
];
    //Added some logging information
    log_value_of_fifth_thing(fifth_thing);

    // This is illustrated as a function call, but there might as well be a=
=20
loop here.
    process_for_a_long_time( std::forward< decltype( thing ) >( fifth_thing=
=20
) );
}

Then the user find the extract part of the function being to big and move=
=20
it to separate function:
template< typename container_handle >
decltype(auto) get_fifth_thing(container_handle && ch)
{
  // Get only the fifth element. We don=E2=80=99t need the rest; OK to free=
 those=20
resources.
  // However, if not assuming ownership, there=E2=80=99s no need to make a =
copy.
  auto && fifth_thing =3D=3D ( * std::forward< container_handle >( ch ) )[ =
5 ];
  //Some loging
  log_value_of_fifth_thing(fifth_thing);
  return fifth_thing;
}

template< typename container_handle >
void operate_on_fifth_thing( container_handle && ch ) {
    // Get only the fifth element. We don=E2=80=99t need the rest; OK to fr=
ee those=20
resources.
       auto && fifth_thing =3D get_fifth_thing(std::forward< container_hand=
le=20
>( ch))

    // This is illustrated as a function call, but there might as well be a=
=20
loop here.
    process_for_a_long_time( std::forward< decltype( thing ) >( fifth_thing=
=20
) );
}

I perceive all above transformation as being acceptable and I think that=20
the programmer expectation that the code will still be valid after them is=
=20
vald. Do you agree?

So lets analyze the situation:
  1. Status quo (no r-value overloads for operator[] this time): The code=
=20
is working before and after transformation the same way.
  2. R-value reference r-value overload for operator[]: The code is working=
=20
before and after transformation the same way.
  3. Value r-value overload for operator[]: In the decltype(auto)=20
get_fifth_thing(container_handle && ch) the auto && fifth_thing =3D=3D ( *=
=20
std::forward< container_handle >( ch ) )[ 5 ]; will cause fifth_thing to be=
=20
type of
      T&&, meaning the return type of function will be reference and that=
=20
will cause auto && fifth_thing =3D get_fifth_thing(std::forward<=20
container_handle >( ch)) to be a dangling reference. The code will be=20
broken by this transormation.

Breaking the connection between lifetime of object and lifetime of=20
expression that should reference for subobject is not good think.


I would like to summarize the arguments pros/cons that come in the thread.=
=20
This is aimed to be objective
  a) addition of T&& value()&&;
     + makes a following code auto&& s =3D temporary_of_optional().value()=
=20
use move semantics
     + std::forward<T>(t).value() correctly forwards value as prvalue
     - auto&& cs =3D temporary_of_optional().value() still not works
  b) addition of T value()&&;
     + makes a: auto&& cs =3D temporary_of_optional().value()
     - breaks connection between lifetime of opt.value() and opt
     - introduce additional temporaries (copies) if the places that=20
captures temporary by const reference: f(temporary_of_optional().value())

In addition we found that for auto&& cs =3D expr;
    a) If we make auto&& cs =3D expr1.expr2 work by changing extending the=
=20
lifetime of object if subobject is captured or having value r-value=20
overloads, the following transformation of code will introduce dangling=20
reference:
        after simple transformation:
        template<typename T>
        delctype(auto) some_getter(T&& t)
        {
           auto&& cs =3D std::forward<T>(t).expr;
           /// some code that causes this transformation to be applied
           return cs;
        }

        auto&& cs =3Df(expr1);
    b) auto&& cs =3D expr1; does not work if the expr1 will return by value=
=20
some kind of expression object that bound references to temporaries (result=
=20
of expression template)

My personal opinion:
  I would recommend to add T&& value()&& because it is introducing the move=
=20
semantics to be trigger seamlessly when a rvalue of optional<T> is used in=
=20
the code. The only drawback of this change is that it will still wont fix=
=20
the auto&& cs =3D f().value() statement.=20

  The only argument for T value()&& presented in this tread was that it=20
will make auto&& cs =3D f().value() work, but will cause performance=20
downgrade in other parts of code, combining that will fact that auto&& cs =
=3D=20
expr; still may create an dangling reference in other context I do not find=
=20
this a good motivation, especially when the main argument to make auto&& cs=
=20
work is that it will allow you to capture any value type in generic code.

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

<div dir=3D"ltr">W dniu sobota, 12 lipca 2014 09:51:15 UTC+2 u=C5=BCytkowni=
k David Krauss napisa=C5=82:<blockquote class=3D"gmail_quote" style=3D"marg=
in: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><d=
iv style=3D"word-wrap:break-word"><br><div><div>On 2014=E2=80=9307=E2=80=93=
12, at 3:27 PM, <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-ma=
ilto=3D"gHq7TNKRVfoJ" onmousedown=3D"this.href=3D'javascript:';return true;=
" onclick=3D"this.href=3D'javascript:';return true;">toma...@gmail.com</a> =
wrote:</div><br><blockquote type=3D"cite"><div dir=3D"ltr">3. The above cod=
e does not work if if the passed Nullable type define &amp;&amp; overload o=
f operator* that returns by value.<br><div>&nbsp;&nbsp;&nbsp; Lifetime of o=
bject bound by auto&amp;&amp; value =3D *std::forward&lt;Nullable&gt;(<wbr>=
nullable); is not the same as lifetime of nullable.<br></div></div></blockq=
uote><div><br></div></div>Yes, but in that case what does the <font face=3D=
"Courier">std::forward</font> express? Reading that function, I would intui=
tively expect <font face=3D"Courier">addressof(value)</font> to become a da=
ngling reference. Any other interpretation requires thinking hard about wha=
t did *<i>not</i>* happen to&nbsp;the result of <font face=3D"Courier">forw=
ard</font>. It wasn=E2=80=99t passed to a function, but absence of some com=
mon thing isn=E2=80=99t a good discriminating factor. (And in fact, it was =
passed to a function, <font face=3D"Courier">operator *</font>.)<div><br></=
div><div>Because&nbsp;<font face=3D"Courier">function_taking_<wbr>pointer(p=
ointer)</font>&nbsp;passes a non-owning observer, <font face=3D"Courier">nu=
llable</font> must live at least through that call. The intent is best expr=
essed by simply&nbsp;<font face=3D"Courier">value =3D * nullable</font>; do=
 not use&nbsp;<font face=3D"Courier">forward()</font>. This can be declared=
 as&nbsp;<font face=3D"Courier">auto &amp;&amp;</font> or <font face=3D"Cou=
rier">auto &amp;</font> equivalently.</div><div><br></div><div>Am I missing=
 something?</div></div></blockquote><div><br>No, your are ok, But let me us=
e your previous example. <br><div class=3D"GGCIKMHDGHB"><div><font face=3D"=
Courier">template&lt; typename container_handle &gt;</font></div><div><font=
 face=3D"Courier">void operate_on_fifth_thing( container_handle &amp;&amp; =
ch ) {</font></div></div><div><font face=3D"Courier">&nbsp; &nbsp; // Get o=
nly the fifth element. We don=E2=80=99t need the rest; OK to free those res=
ources.</font></div><div><font face=3D"Courier">&nbsp; &nbsp; // However, i=
f not assuming ownership, there=E2=80=99s no need to make a&nbsp;copy.</fon=
t></div><div><font face=3D"Courier">&nbsp; &nbsp; auto &amp;&amp; fifth_thi=
ng =3D=3D ( * std::forward&lt; container_handle &gt;( ch ) )[ 5 ];</font></=
div><div><font face=3D"Courier"><br></font></div><div><font face=3D"Courier=
">&nbsp; &nbsp; // This is illustrated as a function call, but there might =
as well be a loop here.</font></div><div><font face=3D"Courier">&nbsp; &nbs=
p; process_for_a_long_time( std::forward&lt; decltype( thing ) &gt;( fifth_=
thing ) );</font></div><div><font face=3D"Courier">}<br><br></font></div>Th=
en assume than we want add some log information:<br><div class=3D"GGCIKMHDG=
HB"><div><font face=3D"Courier">template&lt; typename container_handle &gt;=
</font></div><div><font face=3D"Courier">void operate_on_fifth_thing( conta=
iner_handle &amp;&amp; ch ) {</font></div></div><div><font face=3D"Courier"=
>&nbsp; &nbsp; // Get only the fifth element. We don=E2=80=99t need the res=
t; OK to free those resources.</font></div><div><font face=3D"Courier">&nbs=
p; &nbsp; // However, if not assuming ownership, there=E2=80=99s no need to=
 make a&nbsp;copy.</font></div><div><font face=3D"Courier">&nbsp; &nbsp; au=
to &amp;&amp; fifth_thing =3D=3D ( * std::forward&lt; container_handle &gt;=
( ch ) )[ 5 ];<br>&nbsp;&nbsp;&nbsp; //Added some logging information<br>&n=
bsp;&nbsp;&nbsp; log_value_of_fifth_thing(</font><font face=3D"Courier">fif=
th_thing);</font></div><div><font face=3D"Courier"><br></font></div><div><f=
ont face=3D"Courier">&nbsp; &nbsp; // This is illustrated as a function cal=
l, but there might as well be a loop here.</font></div><div><font face=3D"C=
ourier">&nbsp; &nbsp; process_for_a_long_time( std::forward&lt; decltype( t=
hing ) &gt;( fifth_thing ) );</font></div><div><font face=3D"Courier">}</fo=
nt></div><br>Then the user find the extract part of the function being to b=
ig and move it to separate function:<br><div><span style=3D"font-family: co=
urier new,monospace;">template&lt; typename container_handle &gt;</span></d=
iv><span style=3D"font-family: courier new,monospace;">decltype(auto) get_f=
ifth_thing(container_handle &amp;&amp; ch)<br>{<br></span><div><span style=
=3D"font-family: courier new,monospace;">&nbsp; // Get only the fifth eleme=
nt. We don=E2=80=99t need the rest; OK to free those resources.</span></div=
><div><span style=3D"font-family: courier new,monospace;">&nbsp; // However=
, if not assuming ownership, there=E2=80=99s no need to make a&nbsp;copy.</=
span></div><div><span style=3D"font-family: courier new,monospace;">&nbsp; =
auto &amp;&amp; fifth_thing =3D=3D ( * std::forward&lt; container_handle &g=
t;( ch ) )[ 5 ];<br>&nbsp; //Some loging<br>&nbsp; log_value_of_fifth_thing=
(fifth_thing);</span></div><span style=3D"font-family: courier new,monospac=
e;">&nbsp; return fifth_thing;<br>}</span><br><br><div class=3D"GGCIKMHDGHB=
"><div><font face=3D"Courier">template&lt; typename container_handle &gt;</=
font></div><div><font face=3D"Courier">void operate_on_fifth_thing( contain=
er_handle &amp;&amp; ch ) {<br></font><span style=3D"font-family: courier n=
ew,monospace;">&nbsp;&nbsp;&nbsp; // Get only the fifth element. We don=E2=
=80=99t need the rest; OK to free those resources.</span><br></div></div>&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <font face=3D"Courier">auto &amp;&amp; f=
ifth_thing =3D </font><span style=3D"font-family: courier new,monospace;">g=
et_fifth_thing(</span><span style=3D"font-family: courier new,monospace;">s=
td::forward&lt; container_handle &gt;( ch))</span><div><font face=3D"Courie=
r"><br></font></div><div><font face=3D"Courier">&nbsp; &nbsp; // This is il=
lustrated as a function call, but there might as well be a loop here.</font=
></div><div><font face=3D"Courier">&nbsp; &nbsp; process_for_a_long_time( s=
td::forward&lt; decltype( thing ) &gt;( fifth_thing ) );</font></div><div><=
font face=3D"Courier">}</font></div><br>I perceive all above transformation=
 as being acceptable and I think that the programmer expectation that the c=
ode will still be valid after them is vald. Do you agree?<br><br></div><div=
>So lets analyze the situation:<br>&nbsp; 1. Status quo (no r-value overloa=
ds for operator[] this time): The code is working before and after transfor=
mation the same way.<br>&nbsp; 2. R-value reference r-value overload for op=
erator[]: The code is working before and after transformation the same way.=
<br>&nbsp; 3. Value r-value overload for operator[]: In the <span style=3D"=
font-family: courier new,monospace;">decltype(auto) get_fifth_thing(contain=
er_handle &amp;&amp; ch)</span> the <span style=3D"font-family: courier new=
,monospace;">auto &amp;&amp; fifth_thing =3D=3D ( * std::forward&lt; contai=
ner_handle &gt;( ch ) )[ 5 ]; </span> will cause fifth_thing to be type of<=
br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; T&amp;&amp;, meaning the return type of f=
unction will be reference and that will cause <font face=3D"Courier">auto &=
amp;&amp; fifth_thing =3D </font><span style=3D"font-family: courier new,mo=
nospace;">get_fifth_thing(</span><span style=3D"font-family: courier new,mo=
nospace;">std::forward&lt; container_handle &gt;( ch))</span> to be a dangl=
ing reference. The code will be broken by this transormation.<br><br>Breaki=
ng the connection between lifetime of object and lifetime of expression tha=
t should reference for subobject is not good think.<br><br><br>I would like=
 to summarize the arguments pros/cons that come in the thread. This is aime=
d to be objective<br>&nbsp; a) addition of T&amp;&amp; value()&amp;&amp;;<b=
r>&nbsp;&nbsp;&nbsp;&nbsp; + makes a following code auto&amp;&amp; s =3D te=
mporary_of_optional().value() use move semantics<br>&nbsp;&nbsp;&nbsp;&nbsp=
; + std::forward&lt;T&gt;(t).value() correctly forwards value as prvalue<br=
>&nbsp;&nbsp;&nbsp;&nbsp; - auto&amp;&amp; cs =3D temporary_of_optional().v=
alue() still not works<br>&nbsp; b) addition of T value()&amp;&amp;;<br>&nb=
sp;&nbsp;&nbsp;&nbsp; + makes a: auto&amp;&amp; cs =3D temporary_of_optiona=
l().value()<br>&nbsp;&nbsp;&nbsp;&nbsp; - breaks connection between lifetim=
e of opt.value() and opt<br>&nbsp;&nbsp;&nbsp;&nbsp; - introduce additional=
 temporaries (copies) if the places that captures temporary by const refere=
nce: f(temporary_of_optional().value())<br><br>In addition we found that fo=
r auto&amp;&amp; cs =3D expr;<br>&nbsp;&nbsp;&nbsp; a) If we make auto&amp;=
&amp; cs =3D expr1.expr2 work by changing extending the lifetime of object =
if subobject is captured or having value r-value overloads, the following t=
ransformation of code will introduce dangling reference:<br>&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp; after simple transformation:<br>&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp; template&lt;typename T&gt;<br>&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp; delctype(auto) some_getter(T&amp;&amp; t)<br>&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; {<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp; auto&amp;&amp; cs =3D std::forward&lt;T&gt;(t=
).expr;<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ///=
 some code that causes this transformation to be applied<br>&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; return cs;<br>&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp; }<br><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp; auto&amp;&amp; cs =3Df(expr1);<br>&nbsp;&nbsp;&nbsp; b) auto&amp;&amp;=
 cs =3D expr1; does not work if the expr1 will return by value some kind of=
 expression object that bound references to temporaries (result of expressi=
on template)<br><br>My personal opinion:<br>&nbsp; I would recommend to add=
 T&amp;&amp; value()&amp;&amp; because it is introducing the move semantics=
 to be trigger seamlessly when a rvalue of optional&lt;T&gt; is used in the=
 code. The only drawback of this change is that it will still wont fix the =
auto&amp;&amp; cs =3D f().value() statement. <br><br>&nbsp; The only argume=
nt for T value()&amp;&amp; presented in this tread was that it will make au=
to&amp;&amp; cs =3D f().value() work, but will cause performance downgrade =
in other parts of code, combining that will fact that auto&amp;&amp; cs =3D=
 expr; still may create an dangling reference in other context I do not fin=
d this a good motivation, especially when the main argument to make auto&am=
p;&amp; cs work is that it will allow you to capture any value type in gene=
ric code.<br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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_543_20324844.1405156202697--

.

--Apple-Mail=_A140FED6-ED88-4EAA-B521-AB8B212D20B8
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1


On 2014-07-12, at 5:10 PM, tomaszkam@gmail.com wrote:

>   3. Value r-value overload for operator[]: In the decltype(auto) get_fif=
th_thing(container_handle && ch) theauto && fifth_thing =3D=3D ( * std::for=
ward< container_handle >( ch ) )[ 5 ]; will cause fifth_thing to be type of
>       T&&, meaning the return type of function will be reference and that=
 will cause auto && fifth_thing =3Dget_fifth_thing(std::forward< container_=
handle >( ch)) to be a dangling reference. The code will be broken by this =
transormation.

Actually, the program is ill-formed because the name fifth_thing is an lval=
ue and it will not bind to the returned rvalue reference. If it were change=
d to std::forward< decltype( fifth_thing ) >( fifth_thing ), then your argu=
ment holds, but that's not realistically intuitive. If the problem is inste=
ad fixed by changing the return type to auto (since only special move and f=
orward functions should return xvalues) then my argument holds, but then th=
e user gets one or two copies (only zero or one if they think to std::move(=
 fifth_thing )).

This interaction between decltype(auto) and a named rvalue reference sounds=
 like fodder for a core DR. It's nasty regardless of library policies, and =
considering that a diagnostic is already required, it's fixable. The safe s=
olution, considering the possibility of a bound temporary, is to deduce a n=
on-reference type (return a prvalue), and if the user wants to return an xv=
alue, they should write return std::forward(...). I'm also tempted to say t=
hat returning the name of an rvalue reference should be a copy elision case=
, but this needs further study. (I'm out on a limb, but given these two res=
olutions, then the code would work perfectly.)

Aside from named rvalue references, a policy of prvalue accessors will indu=
ce decltype(auto) to return by prvalue as well.

> Breaking the connection between lifetime of object and lifetime of expres=
sion that should reference for subobject is not good think.

The question is whether or not to reference a subobject of an xvalue at all=
.. An xvalue is usually assumed to be invalidated by the first thing to happ=
en to it, usually any time between getting bound to a parameter and the sem=
icolon. Once it's passed, we don't care what happens to it. Subobjects/comp=
onents of xvalues devolving to prvalues preserves this rule, because there =
is never an actual reference to a subobject in the first place.

> My personal opinion:
>=20
>   The only argument for T value()&& presented in this tread was that it w=
ill make auto&& cs =3D f().value() work, but will cause performance downgra=
de in other parts of code,

Maybe this is what came through the presentation of examples, but the core =
argument is the principle that an xvalue is dead (and reusable) once it goe=
s into any function. I don't think libraries scale well with any other rule=
, although functions that "only" perform access do intuitively seem special=
..

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

--Apple-Mail=_A140FED6-ED88-4EAA-B521-AB8B212D20B8
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014&=
ndash;07&ndash;12, at 5:10 PM, <a href=3D"mailto:tomaszkam@gmail.com">tomas=
zkam@gmail.com</a> wrote:</div><br class=3D"Apple-interchange-newline"><blo=
ckquote type=3D"cite"><div style=3D"font-family: Helvetica; font-size: 12px=
; font-style: normal; font-variant: normal; font-weight: normal; letter-spa=
cing: normal; line-height: normal; orphans: auto; text-align: start; text-i=
ndent: 0px; text-transform: none; white-space: normal; widows: auto; word-s=
pacing: 0px; -webkit-text-stroke-width: 0px;"><div dir=3D"ltr"><div>&nbsp; =
3. Value r-value overload for operator[]: In the<span class=3D"Apple-conver=
ted-space">&nbsp;</span><span style=3D"font-family: 'courier new', monospac=
e;">decltype(auto) get_fifth_thing(container_handle &amp;&amp; ch)</span><s=
pan class=3D"Apple-converted-space">&nbsp;</span>the<span style=3D"font-fam=
ily: 'courier new', monospace;">auto &amp;&amp; fifth_thing =3D=3D ( * std:=
:forward&lt; container_handle &gt;( ch ) )[ 5 ];<span class=3D"Apple-conver=
ted-space">&nbsp;</span></span>will cause fifth_thing to be type of<br>&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp; T&amp;&amp;, meaning the return type of function=
 will be reference and that will cause<span class=3D"Apple-converted-space"=
>&nbsp;</span><font face=3D"Courier">auto &amp;&amp; fifth_thing =3D</font>=
<span style=3D"font-family: 'courier new', monospace;">get_fifth_thing(</sp=
an><span style=3D"font-family: 'courier new', monospace;">std::forward&lt; =
container_handle &gt;( ch))</span><span class=3D"Apple-converted-space">&nb=
sp;</span>to be a dangling reference. The code will be broken by this trans=
ormation.<br></div></div></div></blockquote><div><br></div><div>Actually, t=
he program is ill-formed because the name&nbsp;<font face=3D"Courier">fifth=
_thing</font> is an lvalue and it will not bind to the returned rvalue refe=
rence. If it were changed to <font face=3D"Courier">std::forward&lt; declty=
pe( fifth_thing ) &gt;( fifth_thing )</font>, then your argument holds, but=
 that&rsquo;s not realistically intuitive. If the problem is instead fixed =
by changing the return type to&nbsp;<font face=3D"Courier">auto</font>&nbsp=
;(since only special&nbsp;<font face=3D"Courier">move</font>&nbsp;and&nbsp;=
<font face=3D"Courier">forward</font>&nbsp;functions should return xvalues)=
 then my argument holds, but then the user gets one or two copies (only zer=
o or one if they think to <font face=3D"Courier">std::move( fifth_thing )</=
font>).</div><div><br></div><div>This interaction between <font face=3D"Cou=
rier">decltype(auto)</font> and a named rvalue reference sounds like fodder=
 for a core DR. It&rsquo;s nasty regardless of library policies, and consid=
ering that a diagnostic is already required, it&rsquo;s fixable. The safe s=
olution, considering the possibility of a bound temporary, is to deduce a n=
on-reference type (return a prvalue), and if the user wants to return an xv=
alue, they should write <font face=3D"Courier">return std::forward(&hellip;=
)</font>. I&rsquo;m also tempted to say that returning the name of an rvalu=
e reference should be a copy elision case, but this needs further study. (I=
&rsquo;m out on a limb, but given these two resolutions, then the code woul=
d work perfectly.)</div><div><br></div><div>Aside from named rvalue referen=
ces, a policy of prvalue accessors will induce <font face=3D"Courier">declt=
ype(auto)</font> to return by prvalue as well.</div><div><br></div><blockqu=
ote type=3D"cite"><div style=3D"font-family: Helvetica; font-size: 12px; fo=
nt-style: normal; font-variant: normal; font-weight: normal; letter-spacing=
: normal; line-height: normal; orphans: auto; text-align: start; text-inden=
t: 0px; text-transform: none; white-space: normal; widows: auto; word-spaci=
ng: 0px; -webkit-text-stroke-width: 0px;"><div dir=3D"ltr"><div>Breaking th=
e connection between lifetime of object and lifetime of expression that sho=
uld reference for subobject is not good think.<br></div></div></div></block=
quote><div><br></div><div>The question is whether or not to reference a sub=
object of an xvalue at all. An xvalue is usually assumed to be invalidated =
by the first thing to happen to it, usually any time between getting bound =
to a parameter and the semicolon. Once it&rsquo;s passed, we don&rsquo;t ca=
re what happens to it. Subobjects/components of xvalues devolving to prvalu=
es preserves this rule, because there is never an actual reference to a sub=
object in the first place.</div><div><br></div><blockquote type=3D"cite"><d=
iv style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; fo=
nt-variant: normal; font-weight: normal; letter-spacing: normal; line-heigh=
t: normal; orphans: auto; text-align: start; text-indent: 0px; text-transfo=
rm: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-tex=
t-stroke-width: 0px;"><div dir=3D"ltr"><div>My personal opinion:<br><br>&nb=
sp; The only argument for T value()&amp;&amp; presented in this tread was t=
hat it will make auto&amp;&amp; cs =3D f().value() work, but will cause per=
formance downgrade in other parts of code, </div></div></div></blockquote><=
div><br></div><div>Maybe this is what came through the presentation of exam=
ples, but the core argument is the principle that an xvalue is dead (and re=
usable) once it goes into any function. I don&rsquo;t think libraries scale=
 well with any other rule, although functions that &ldquo;only&rdquo; perfo=
rm access do intuitively seem special.</div><div><br></div></div></body></h=
tml>

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

--Apple-Mail=_A140FED6-ED88-4EAA-B521-AB8B212D20B8--

.

------=_Part_27_187718.1405169833294
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



W dniu sobota, 12 lipca 2014 13:14:57 UTC+2 u=C5=BCytkownik David Krauss na=
pisa=C5=82:
>
>
> On 2014=E2=80=9307=E2=80=9312, at 5:10 PM, toma...@gmail.com <javascript:=
> wrote:
>
>   3. Value r-value overload for operator[]: In the decltype(auto)=20
> get_fifth_thing(container_handle && ch) theauto && fifth_thing =3D=3D ( *=
=20
> std::forward< container_handle >( ch ) )[ 5 ]; will cause fifth_thing to=
=20
> be type of
>       T&&, meaning the return type of function will be reference and that=
=20
> will cause auto && fifth_thing =3Dget_fifth_thing(std::forward<=20
> container_handle >( ch)) to be a dangling reference. The code will be=20
> broken by this transormation.
>
>
> Actually, the program is ill-formed because the name fifth_thing is an=20
> lvalue and it will not bind to the returned rvalue reference. If it were=
=20
> changed to std::forward< decltype( fifth_thing ) >( fifth_thing ), then=
=20
> your argument holds, but that=E2=80=99s not realistically intuitive. If t=
he problem=20
> is instead fixed by changing the return type to auto (since only special=
=20
> move and forward functions should return xvalues) then my argument holds,=
=20
> but then the user gets one or two copies (only zero or one if they think =
to std::move(=20
> fifth_thing )).
>
> To be clear, I understand you are proposing:=20
template< typename container_handle >
auto get_fifth_thing(container_handle && ch)
{
  // Get only the fifth element. We don=E2=80=99t need the rest; OK to free=
 those=20
resources.
  // However, if not assuming ownership, there=E2=80=99s no need to make a =
copy.
  auto && fifth_thing =3D=3D ( * std::forward< container_handle >( ch ) )[ =
5 ];
  //Some loging
  log_value_of_fifth_thing(fifth_thing);
  return fifth_thing;
}=20
But then invocation of get_fifth_thing will always introduce an temporary=
=20
even if proper lvalue of container_handle is passed as argument (and this=
=20
time it must be an copy). Until now we were discussing only additional=20
temporaries in the case of rvalue passed to such function. I think that=20
adding additional temporary in any case is not acceptable in generic=20
context. Also it disallows modification of return if lvalue is passed. This=
=20
lets us to desing when we have two separate functions get_fifth_thing for=
=20
lvalue and rvalues with kills the idea of forwarding (or we will have the=
=20
changes mentonied by you below, but they will have further consequences).

I agree with you that return should be std::forward< decltype( fifth_thing=
=20
) >( fifth_thing ). But when I checked it with gcc-4.9.0 the return type is=
=20
deduced to be T&, see http://goo.gl/ARPOix. I am not sure if it is a bug (I=
=20
think it should be) or rule has been changed.
 =20

> This interaction between decltype(auto) and a named rvalue reference=20
> sounds like fodder for a core DR. It=E2=80=99s nasty regardless of librar=
y=20
> policies, and considering that a diagnostic is already required, it=E2=80=
=99s=20
> fixable. The safe solution, considering the possibility of a bound=20
> temporary, is to deduce a non-reference type (return a prvalue), and if t=
he=20
> user wants to return an xvalue, they should write return std::forward(=E2=
=80=A6).=20
> I=E2=80=99m also tempted to say that returning the name of an rvalue refe=
rence=20
> should be a copy elision case, but this needs further study. (I=E2=80=99m=
 out on a=20
> limb, but given these two resolutions, then the code would work perfectly=
..)
>
>  =20
This will introduce a lot of temporaries in the code. Let assume we have:
  struct A
  {
     struct B
     {
          std::vector<only-copyable> members;=20
     } b;
  };
 =20
And have following getter functions that uses delctype(auto):
  template<typename T>
  decltype(auto) get_B(T&& t) { return std::forward<T>(t).b; }

  template<typename T>
  decltype(auto) get_members(T&& t) { return=20
get_b(std::forward<T>(t)).members; }

  template<typename T>
  decltype(auto) get_front(T&& t) { return=20
get_members(std::forward<T>(T)).front(); }

The following code:
  auto cs  =3D get_front(A());
May copy members of vector 2 times. Because get_B will return by value (and=
=20
copy members), then get_members will return by value. This may be stacked=
=20
as many times as you want.
I think it not acceptable performance loss to only get auto&& cs;

Aside from named rvalue references, a policy of prvalue accessors will=20
> induce decltype(auto) to return by prvalue as well.
>

So with current language the prvalue policy will work only if you dont use=
=20
auto&& cs in function and then return cs, and the prvalue policy was=20
introduced to make this auto&& cs actually work. Seems you found=20
contradicting arguments.=20

>
> Breaking the connection between lifetime of object and lifetime of=20
> expression that should reference for subobject is not good think.
>
>
> The question is whether or not to reference a subobject of an xvalue at=
=20
> all. An xvalue is usually assumed to be invalidated by the first thing to=
=20
> happen to it, usually any time between getting bound to a parameter and t=
he=20
> semicolon. Once it=E2=80=99s passed, we don=E2=80=99t care what happens t=
o it.=20
> Subobjects/components of xvalues devolving to prvalues preserves this rul=
e,=20
> because there is never an actual reference to a subobject in the first=20
> place.
>
> "Once it=E2=80=99s passed, we don=E2=80=99t care what happens to it." And=
 propably this=20
argument let to desing that makes:
   auto&& cs =3D f().member;
Work be extending liftime of whole object. But there is a think with the=20
RAII idom it is important to know when the object is actually destroyed.=20
The some think let to broken move-by-swap iimplemenation=20
(http://scottmeyers.blogspot.com/2014/06/the-drawbacks-of-implementing-move=
..html),=20
copy-and-swap is still valid, because it destroy previous values at the=20
point of assigment.

The resultion that makes auto&& cs =3D f().member; work, has simliar=20
conseuqence:
struct Result
{
  unique_lock<std::mutex> m;
  std::string member;
};
Result f();

Lets assume you have found a following code block causing deadlock.
{
   auto&& s =3D f().member;
   unique_lock<std::mutex> lock(same_mutex_as_f_uses);
 }
I think that every programmer will check the defintion of the member type=
=20
(hold by s) to check if the any lock is held here, but I think would never=
=20
expect that it is hold bu the result
of f() being held under the hood by reference s, even if not explicitly=20
mentonied. This whole behavior is really more counter-intuitive than having=
=20
the line auto&& s =3D f().member; create
a dangling reference, which may be detected by simple memory sanitizing=20
tool. The lock would not be.
Actually I think that this behaviour is insane in light of resource=20
handlers.

And this is the reason I perceive this whole "make auto&& cs =3D expr"=20
movement work, even if it kills performance, introduce more=20
counter-intutive behavior as bad direction.

My personal opinion:
>
>   The only argument for T value()&& presented in this tread was that it=
=20
> will make auto&& cs =3D f().value() work, but will cause performance=20
> downgrade in other parts of code,=20
>
>
> Maybe this is what came through the presentation of examples, but the cor=
e=20
> argument is the principle that an xvalue is dead (and reusable) once it=
=20
> goes into any function. I don=E2=80=99t think libraries scale well with a=
ny other=20
> rule, although functions that =E2=80=9Conly=E2=80=9D perform access do in=
tuitively seem=20
> special.
>

But in the generic code (as my before example) we are not knowing if we=20
have handling rvalue/lvalue, this is whole idea behind it. And in may=20
examples the container goes into the get_fifth_element and it no longer=20
used, so I think this example fits the argument.=20

--=20

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

------=_Part_27_187718.1405169833294
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>W dniu sobota, 12 lipca 2014 13:14:57 UTC+2 u=C5=
=BCytkownik David Krauss napisa=C5=82:<blockquote class=3D"gmail_quote" sty=
le=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left=
: 1ex;"><div style=3D"word-wrap:break-word"><br><div><div>On 2014=E2=80=930=
7=E2=80=9312, at 5:10 PM, <a href=3D"javascript:" target=3D"_blank" gdf-obf=
uscated-mailto=3D"0lgZYvrmc0AJ" onmousedown=3D"this.href=3D'javascript:';re=
turn true;" onclick=3D"this.href=3D'javascript:';return true;">toma...@gmai=
l.com</a> wrote:</div><br><blockquote type=3D"cite"><div style=3D"font-fami=
ly:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weig=
ht:normal;letter-spacing:normal;line-height:normal;text-align:start;text-in=
dent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div dir=
=3D"ltr"><div>&nbsp; 3. Value r-value overload for operator[]: In the<span>=
&nbsp;</span><span style=3D"font-family:'courier new',monospace">decltype(a=
uto) get_fifth_thing(container_<wbr>handle &amp;&amp; ch)</span><span>&nbsp=
;</span>the<span style=3D"font-family:'courier new',monospace">auto &amp;&a=
mp; fifth_thing =3D=3D ( * std::forward&lt; container_handle &gt;( ch ) )[ =
5 ];<span>&nbsp;</span></span>will cause fifth_thing to be type of<br>&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp; T&amp;&amp;, meaning the return type of function =
will be reference and that will cause<span>&nbsp;</span><font face=3D"Couri=
er">auto &amp;&amp; fifth_thing =3D</font><span style=3D"font-family:'couri=
er new',monospace">get_fifth_thing(</span><span style=3D"font-family:'couri=
er new',monospace">std::forward&lt; container_handle &gt;( ch))</span><span=
>&nbsp;</span>to be a dangling reference. The code will be broken by this t=
ransormation.<br></div></div></div></blockquote><div><br></div><div>Actuall=
y, the program is ill-formed because the name&nbsp;<font face=3D"Courier">f=
ifth_thing</font> is an lvalue and it will not bind to the returned rvalue =
reference. If it were changed to <font face=3D"Courier">std::forward&lt; de=
cltype( fifth_thing ) &gt;( fifth_thing )</font>, then your argument holds,=
 but that=E2=80=99s not realistically intuitive. If the problem is instead =
fixed by changing the return type to&nbsp;<font face=3D"Courier">auto</font=
>&nbsp;(since only special&nbsp;<font face=3D"Courier">move</font>&nbsp;and=
&nbsp;<font face=3D"Courier">forward</font>&nbsp;<wbr>functions should retu=
rn xvalues) then my argument holds, but then the user gets one or two copie=
s (only zero or one if they think to <font face=3D"Courier">std::move( fift=
h_thing )</font>).</div><div><br></div></div></div></blockquote><div>To be =
clear, I understand you are proposing: <br></div><div><div><span style=3D"f=
ont-family:courier new,monospace">template&lt; typename container_handle &g=
t;</span></div><span style=3D"font-family:courier new,monospace">auto get_f=
ifth_thing(container_<wbr>handle &amp;&amp; ch)<br>{<br></span><div class=
=3D"GGCIKMHDGHB"><div><span style=3D"font-family:courier new,monospace">&nb=
sp; // Get only the fifth element. We don=E2=80=99t need the rest; OK to fr=
ee those resources.</span></div><div><span style=3D"font-family:courier new=
,monospace">&nbsp; // However, if not assuming ownership, there=E2=80=99s n=
o need to make a&nbsp;copy.</span></div></div><div><span style=3D"font-fami=
ly:courier new,monospace">&nbsp; auto &amp;&amp; fifth_thing =3D=3D ( * std=
::forward&lt; container_handle &gt;( ch ) )[ 5 ];<br>&nbsp; //Some loging<b=
r>&nbsp; log_value_of_fifth_thing(<wbr>fifth_thing);</span></div><span styl=
e=3D"font-family:courier new,monospace">&nbsp; return fifth_thing;<br>}</sp=
an> <br>But
 then invocation of get_fifth_thing will always introduce an temporary even=
 if proper lvalue of=20
container_handle is passed as argument (and this time it must be an copy). =
Until now we were discussing=20
only additional temporaries in the case of rvalue passed to such=20
function. I think that adding additional temporary in any case is not accep=
table in generic context. Also it disallows modification of return if lvalu=
e is passed. This lets us to desing when we have two separate functions <sp=
an style=3D"font-family:courier new,monospace">get_fifth_thing </span>for l=
value and rvalues with kills the idea of forwarding (or we will have the ch=
anges mentonied by you below, but they will have further consequences).<br>=
<br>I agree with you that return should be <font face=3D"Courier">std::forw=
ard&lt; decltype( fifth_thing ) &gt;( fifth_thing ). </font>But when I chec=
ked it with gcc-4.9.0 the return type is deduced to be T&amp;, see http://g=
oo.gl/ARPOix. I am not sure if it is a bug (I think it should be) or rule h=
as been changed.<br>&nbsp; <br></div><blockquote class=3D"gmail_quote" styl=
e=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left:=
 1ex;"><div style=3D"word-wrap:break-word"><div><div></div><div>This intera=
ction between <font face=3D"Courier">decltype(auto)</font> and a named rval=
ue reference sounds like fodder for a core DR. It=E2=80=99s nasty regardles=
s of library policies, and considering that a diagnostic is already require=
d, it=E2=80=99s fixable. The safe solution, considering the possibility of =
a bound temporary, is to deduce a non-reference type (return a prvalue), an=
d if the user wants to return an xvalue, they should write <font face=3D"Co=
urier">return std::forward(=E2=80=A6)</font>. I=E2=80=99m also tempted to s=
ay that returning the name of an rvalue reference should be a copy elision =
case, but this needs further study. (I=E2=80=99m out on a limb, but given t=
hese two resolutions, then the code would work perfectly.)</div><div><br></=
div></div></div></blockquote><div>&nbsp; <br>This will introduce a lot of t=
emporaries in the code. Let assume we have:<br>&nbsp; struct A<br>&nbsp; {<=
br>&nbsp;&nbsp;&nbsp;&nbsp; struct B<br>&nbsp;&nbsp;&nbsp;&nbsp; {<br>&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; std::vector&lt;only-copya=
ble&gt; members; <br>&nbsp;&nbsp;&nbsp;&nbsp; } b;<br>&nbsp; };<br>&nbsp; <=
br>And have following getter functions that uses delctype(auto):<br>&nbsp; =
template&lt;typename T&gt;<br>&nbsp; decltype(auto) get_B(T&amp;&amp; t) { =
return std::forward&lt;T&gt;(t).b; }<br><br>&nbsp; template&lt;typename T&g=
t;<br>&nbsp; decltype(auto) get_members(T&amp;&amp; t) { return get_b(std::=
forward&lt;T&gt;(t)).members; }<br><br>&nbsp; template&lt;typename T&gt;<br=
>&nbsp; decltype(auto) get_front(T&amp;&amp; t) { return get_members(std::f=
orward&lt;T&gt;(T)).front(); }<br><br>The following code:<br>&nbsp; auto cs=
&nbsp; =3D get_front(A());<br>May copy members of vector 2 times. Because g=
et_B will return by value (and copy members), then get_members will return =
by value. This may be stacked as many times as you want.<br>I think it not =
acceptable performance loss to only get auto&amp;&amp; cs;<br><br></div><bl=
ockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border=
-left: 1px #ccc solid;padding-left: 1ex;"><div style=3D"word-wrap:break-wor=
d"><div><div></div><div>Aside from named rvalue references, a policy of prv=
alue accessors will induce <font face=3D"Courier">decltype(auto)</font> to =
return by prvalue as well.</div></div></div></blockquote><div><br>So with c=
urrent language the prvalue policy will work only if you dont use auto&amp;=
&amp; cs in function and then return cs, and the prvalue policy was introdu=
ced to make this auto&amp;&amp; cs actually work. Seems you found contradic=
ting arguments. <br></div><blockquote class=3D"gmail_quote" style=3D"margin=
: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div=
 style=3D"word-wrap:break-word"><div><div><br></div><blockquote type=3D"cit=
e"><div style=3D"font-family:Helvetica;font-size:12px;font-style:normal;fon=
t-variant:normal;font-weight:normal;letter-spacing:normal;line-height:norma=
l;text-align:start;text-indent:0px;text-transform:none;white-space:normal;w=
ord-spacing:0px"><div dir=3D"ltr"><div>Breaking the connection between life=
time of object and lifetime of expression that should reference for subobje=
ct is not good think.<br></div></div></div></blockquote><div><br></div><div=
>The question is whether or not to reference a subobject of an xvalue at al=
l. An xvalue is usually assumed to be invalidated by the first thing to hap=
pen to it, usually any time between getting bound to a parameter and the se=
micolon. Once it=E2=80=99s passed, we don=E2=80=99t care what happens to it=
.. Subobjects/components of xvalues devolving to prvalues preserves this rul=
e, because there is never an actual reference to a subobject in the first p=
lace.</div><div><br></div></div></div></blockquote><div>"Once it=E2=80=99s =
passed, we don=E2=80=99t care what happens to it." And propably this argume=
nt let to desing that makes:<br>&nbsp;&nbsp; auto&amp;&amp; cs =3D f().memb=
er;<br>Work be extending liftime of whole object. But there is a think with=
 the RAII idom it is important to know when the object is actually destroye=
d. The some think let to broken move-by-swap iimplemenation (http://scottme=
yers.blogspot.com/2014/06/the-drawbacks-of-implementing-move.html), copy-an=
d-swap is still valid, because it destroy previous values at the point of a=
ssigment.<br><br>The resultion that makes auto&amp;&amp; cs =3D f().member;=
 work, has simliar conseuqence:<br>struct Result<br>{<br>&nbsp; unique_lock=
&lt;std::mutex&gt; m;<br>&nbsp; std::string member;<br>};<br>Result f();<br=
><br>Lets assume you have found a following code block causing deadlock.<br=
>{<br>&nbsp;&nbsp; auto&amp;&amp; s =3D f().member;<br>&nbsp;&nbsp; unique_=
lock&lt;std::mutex&gt; lock(same_mutex_as_f_uses);<br>&nbsp;}<br>I think th=
at every programmer will check the defintion of the member type (hold by s)=
 to check if the any lock is held here, but I think would never expect that=
 it is hold bu the result<br>of f() being held under the hood by reference =
s, even if not explicitly mentonied. This whole behavior is really more cou=
nter-intuitive than having the line auto&amp;&amp; s =3D f().member; create=
<br>a dangling reference, which may be detected by simple memory sanitizing=
 tool. The lock would not be.<br>Actually I think that this behaviour is in=
sane in light of resource handlers.<br><br>And this is the reason I perceiv=
e this whole "make auto&amp;&amp; cs =3D expr" movement work, even if it ki=
lls performance, introduce more counter-intutive behavior as bad direction.=
<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div style=3D"wo=
rd-wrap:break-word"><div><div></div><blockquote type=3D"cite"><div style=3D=
"font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal=
;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:sta=
rt;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"=
><div dir=3D"ltr"><div>My personal opinion:<br><br>&nbsp; The only argument=
 for T value()&amp;&amp; presented in this tread was that it will make auto=
&amp;&amp; cs =3D f().value() work, but will cause performance downgrade in=
 other parts of code, </div></div></div></blockquote><div><br></div><div>Ma=
ybe this is what came through the presentation of examples, but the core ar=
gument is the principle that an xvalue is dead (and reusable) once it goes =
into any function. I don=E2=80=99t think libraries scale well with any othe=
r rule, although functions that =E2=80=9Conly=E2=80=9D perform access do in=
tuitively seem special.</div></div></div></blockquote><div><br>But in the g=
eneric code (as my before example) we are not knowing if we have handling r=
value/lvalue, this is whole idea behind it. And in may examples the contain=
er goes into the get_fifth_element and it no longer used, so I think this e=
xample fits the argument. <br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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_27_187718.1405169833294--

.

------=_Part_5_15173946.1405171518705
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


>
>
> Maybe this is what came through the presentation of examples, but the cor=
e=20
> argument is the principle that an xvalue is dead (and reusable) once it=
=20
> goes into any function. I don=E2=80=99t think libraries scale well with a=
ny other=20
> rule, although functions that =E2=80=9Conly=E2=80=9D perform access do in=
tuitively seem=20
> special.
>
> Actually in this thread we presented a lot of examples for which the=20
generic code (I assume that by libraries you mean the one using generic=20
code), with the set of following rules:
   a) auto&& cs does not work in generality
   b) we have rvalue reference overloads return rvalue references
and was requiring separte treatment for rvalues and lvalues or imposing=20
performance loss when:
   c) we have rvalue reference overloads return value
Futhermore the second set of rules failed to quaranty that auto&& cs will=
=20
always work. No examples
for situation when T&& op()&& overloads breaks something that works before=
=20
their introduction was presented.

So in my opinion this treads rather shows up that the T&& op()&& and zero=
=20
guarantee for auto&& is set of rule with the libraries scares well.

As an example, if the code I have presented will be rewritten using with=20
instead of auto&&:
template< typename container_handle >
decltype(auto) get_fifth_thing(container_handle && ch)
{
  return with(( * std::forward< container_handle >( ch ) )[ 5 ]
    [](auto&& fifth_thing) {
      log_value_of_fifth_thing(fifth_thing);
       return fifth_thing;
    });
}

template< typename container_handle >
void operate_on_fifth_thing( container_handle && ch ) {
    with(get_fifth_thing(std::forward< container_handle >( ch))
      [](auto&& fifth_thing){
        process_for_a_long_time( std::forward< decltype( thing ) >(=20
fifth_thing ) );
      });   =20
}

The code works in any case, even if the container_handle is lazy evaluator=
=20
returning by value.=20

--=20

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

------=_Part_5_15173946.1405171518705
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div style=3D=
"word-wrap:break-word"><div><br><div>Maybe this is what came through the pr=
esentation of examples, but the core argument is the principle that an xval=
ue is dead (and reusable) once it goes into any function. I don=E2=80=99t t=
hink libraries scale well with any other rule, although functions that =E2=
=80=9Conly=E2=80=9D perform access do intuitively seem special.</div><div><=
br></div></div></div></blockquote><div>Actually in this thread we presented=
 a lot of examples for which the generic code (I assume that by libraries y=
ou mean the one using generic code), with the set of following rules:<br>&n=
bsp;&nbsp; a) auto&amp;&amp; cs does not work in generality<br>&nbsp;&nbsp;=
 b) we have rvalue reference overloads return rvalue references<br>and was =
requiring separte treatment for rvalues and lvalues or imposing performance=
 loss when:<br>&nbsp;&nbsp; c) we have rvalue reference overloads return va=
lue<br>Futhermore the second set of rules failed to quaranty that auto&amp;=
&amp; cs will always work. No examples<br>for situation when T&amp;&amp; op=
()&amp;&amp; overloads breaks something that works before their introductio=
n was presented.<br><br>So in my opinion this treads rather shows up that t=
he T&amp;&amp; op()&amp;&amp; and zero guarantee for auto&amp;&amp; is set =
of rule with the libraries scares well.<br><br>As an example, if the code I=
 have presented will be rewritten using with instead of auto&amp;&amp;:<br>=
<div><span style=3D"font-family:courier new,monospace">template&lt; typenam=
e container_handle &gt;</span></div><span style=3D"font-family:courier new,=
monospace">decltype(auto) get_fifth_thing(container_<wbr>handle &amp;&amp; =
ch)<br>{<br>&nbsp; return with(</span><span style=3D"font-family:courier ne=
w,monospace">( * std::forward&lt; container_handle &gt;( ch ) )[ 5 ]<br>&nb=
sp;&nbsp;&nbsp; [](auto&amp;&amp; </span><span style=3D"font-family:courier=
 new,monospace">fifth_thing) {</span><br><div><span style=3D"font-family:co=
urier new,monospace">&nbsp; &nbsp;&nbsp;&nbsp; log_value_of_fifth_thing(<wb=
r>fifth_thing);</span></div><span style=3D"font-family:courier new,monospac=
e">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; return fifth_thing;<br>&nbsp;&nbsp;=
&nbsp; });<br>}</span><br><br><div><div><font face=3D"Courier">template&lt;=
 typename container_handle &gt;</font></div><div><div class=3D"GGCIKMHDGHB"=
><font face=3D"Courier">void operate_on_fifth_thing( container_handle &amp;=
&amp; ch ) {<br>&nbsp;&nbsp;&nbsp; with(</font><span style=3D"font-family:c=
ourier new,monospace">get_fifth_thing(</span><span style=3D"font-family:cou=
rier new,monospace">std::forward&lt; container_handle &gt;( ch))</span><div=
><font face=3D"Courier">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [](auto&amp;&amp; </=
font><font face=3D"Courier"><font face=3D"Courier">fifth_thing)</font>{<br>=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </font><font face=3D"Courier"><f=
ont face=3D"Courier">process_for_a_long_time( std::forward&lt; decltype( th=
ing ) &gt;( fifth_thing ) );</font><br></font></div></div><span style=3D"fo=
nt-family:courier new,monospace"></span></div></div><div><font face=3D"Cour=
ier">&nbsp; &nbsp; &nbsp; });&nbsp; &nbsp; <br></font></div><div><font face=
=3D"Courier">}</font></div><br>The code works in any case, even if the cont=
ainer_handle is lazy evaluator returning by value. <br><br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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_5_15173946.1405171518705--

.

--Apple-Mail=_FDCA0442-3931-4935-B9D3-C87EA8CBF473
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1


On 2014-07-12, at 8:57 PM, tomaszkam@gmail.com wrote:

> This will introduce a lot of temporaries in the code.

Most code tends to have a lot of temporaries anyway. Temporaries are a prod=
uct of value semantics, as opposed to reference semantics. Since rvalue ref=
erences introduce concerns of aliasing and referent lifetime, I think the l=
anguage should have the programmer mention std::move or std::forward when t=
hey are in effect, and specifically for the thing being referenced, not onl=
y its container.

No proposal from me will necessitate more temporaries :) . I like performan=
ce as much as anyone, but only within the limits of safety.

As for the rest, I think you're reading too much into the differences. The =
dilemma is between two different, equally expressive, conventions favoring =
references or values. Performance and safety are both possible with either.

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

--Apple-Mail=_FDCA0442-3931-4935-B9D3-C87EA8CBF473
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014&=
ndash;07&ndash;12, at 8:57 PM, <a href=3D"mailto:tomaszkam@gmail.com">tomas=
zkam@gmail.com</a> wrote:</div><br class=3D"Apple-interchange-newline"><blo=
ckquote type=3D"cite"><div style=3D"font-family: Helvetica; font-size: 12px=
; font-style: normal; font-variant: normal; font-weight: normal; letter-spa=
cing: normal; line-height: normal; orphans: auto; text-align: start; text-i=
ndent: 0px; text-transform: none; white-space: normal; widows: auto; word-s=
pacing: 0px; -webkit-text-stroke-width: 0px;"><div dir=3D"ltr">This will in=
troduce a lot of temporaries in the code. </div></div></blockquote><div><br=
></div><div>Most code tends to have a lot of temporaries anyway. Temporarie=
s are a product of value semantics, as opposed to reference semantics. Sinc=
e rvalue references introduce concerns of aliasing and referent lifetime, I=
 think the language should have the programmer mention std::move or std::fo=
rward when they are in effect, and specifically for the thing being referen=
ced, not only its container.</div><div><br></div><div>No proposal from me w=
ill necessitate more temporaries :) . I like performance as much as anyone,=
 but only within the limits of safety.</div></div><br><div>As for the rest,=
 I think you&rsquo;re reading too much into the differences. The dilemma is=
 between two different, equally expressive, conventions favoring references=
 or values. Performance and safety are both possible with either.</div><div=
><br></div></body></html>

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

--Apple-Mail=_FDCA0442-3931-4935-B9D3-C87EA8CBF473--

.

------=_Part_136_28872460.1405185804717
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

W dniu sobota, 12 lipca 2014 17:24:03 UTC+2 u=C5=BCytkownik David Krauss na=
pisa=C5=82:
>
>
> On 2014=E2=80=9307=E2=80=9312, at 8:57 PM, toma...@gmail.com <javascript:=
> wrote:
>
> This will introduce a lot of temporaries in the code.=20
>
>
> Most code tends to have a lot of temporaries anyway. Temporaries are a=20
> product of value semantics, as opposed to reference semantics. Since rval=
ue=20
> references introduce concerns of aliasing and referent lifetime, I think=
=20
> the language should have the programmer mention std::move or std::forward=
=20
> when they are in effect, and specifically for the thing being referenced,=
=20
> not only its container.
>

While having  temporaries introduced for classes designed to be used as=20
values (int, boost::gregorian::dates)  is perfectly fine, but  doing the=20
same for heavyweight classes is an issue. But in the generic code we aim to=
=20
handle both, so to appropriate handle heavyweight classes we must avoid=20
temporaries, even for value ones. This is actually reason for which in=20
optional<T> we define:=20
  T& value();
  T const& value() const;
Instead of simply:
  T value() const;
And if the second design was present then introduction of:
  T value() &&;
 Would be a mere optimization.


> No proposal from me will necessitate more temporaries :) . I like=20
> performance as much as anyone, but only within the limits of safety.
>
> As for the rest, I think you=E2=80=99re reading too much into the differe=
nces. The=20
> dilemma is between two different, equally expressive, conventions favorin=
g=20
> references or values. Performance and safety are both possible with eithe=
r.
>
> In my opinion the reference favoring convertion can work without issues=
=20
with classes that are designed to have value semantics but not otherway and=
=20
that is the reason I prefer to use it in generic context.

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

<div dir=3D"ltr">W dniu sobota, 12 lipca 2014 17:24:03 UTC+2 u=C5=BCytkowni=
k David Krauss napisa=C5=82:<blockquote class=3D"gmail_quote" style=3D"marg=
in: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><d=
iv style=3D"word-wrap:break-word"><br><div><div>On 2014=E2=80=9307=E2=80=93=
12, at 8:57 PM, <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-ma=
ilto=3D"-Xx-g5MoDa8J" onmousedown=3D"this.href=3D'javascript:';return true;=
" onclick=3D"this.href=3D'javascript:';return true;">toma...@gmail.com</a> =
wrote:</div><br><blockquote type=3D"cite"><div style=3D"font-family:Helveti=
ca;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;=
letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;t=
ext-transform:none;white-space:normal;word-spacing:0px"><div dir=3D"ltr">Th=
is will introduce a lot of temporaries in the code. </div></div></blockquot=
e><div><br></div><div>Most code tends to have a lot of temporaries anyway. =
Temporaries are a product of value semantics, as opposed to reference seman=
tics. Since rvalue references introduce concerns of aliasing and referent l=
ifetime, I think the language should have the programmer mention std::move =
or std::forward when they are in effect, and specifically for the thing bei=
ng referenced, not only its container.</div></div></div></blockquote><div><=
br>While having&nbsp; temporaries introduced for classes designed to be use=
d as=20
values (int, boost::gregorian::dates)&nbsp; is perfectly fine, but&nbsp; do=
ing the
 same for heavyweight classes is an issue. But in the generic code we aim=
=20
to handle both, so to appropriate handle heavyweight classes we must=20
avoid temporaries, even for value ones. This is actually reason for which
 in optional&lt;T&gt; we define: <br>&nbsp; T&amp; value();<br>&nbsp; T con=
st&amp; value() const;<br>Instead of simply:<br>&nbsp; T value() const;<br>=
And if the second design was present then introduction of:<br>&nbsp; T valu=
e() &amp;&amp;;<br>&nbsp;Would be a mere optimization.<br><br></div><blockq=
uote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-lef=
t: 1px #ccc solid;padding-left: 1ex;"><div style=3D"word-wrap:break-word"><=
div><div><br></div><div>No proposal from me will necessitate more temporari=
es :) . I like performance as much as anyone, but only within the limits of=
 safety.</div></div><br><div>As for the rest, I think you=E2=80=99re readin=
g too much into the differences. The dilemma is between two different, equa=
lly expressive, conventions favoring references or values. Performance and =
safety are both possible with either.</div><div><br></div></div></blockquot=
e><div>In my opinion the reference favoring convertion can work without iss=
ues with classes that are designed to have value semantics but not otherway=
 and that is the reason I prefer to use it in generic context.<br><br></div=
></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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_136_28872460.1405185804717--

.