Topic: Proposal. In an return statement expression, a


Author: Richard Smith <richard@metafoo.co.uk>
Date: Mon, 21 Apr 2014 11:32:26 -0700
Raw View
--047d7b418c8b9f23ce04f791b899
Content-Type: text/plain; charset=UTF-8

On Mon, Apr 21, 2014 at 11:13 AM, Mikhail Semenov <
mikhailsemenov1957@gmail.com> wrote:

> I would like to propose: in a return statement expression if a local
> variable (which is not defined as an lvalue reference) and occurs only once
> should be treated as an rvalue.
>
> If this is adopted we won't have to write forwarding in most cases.
>
> Instead of writing:
>
> template <class ... T>
> void g(T&& ... t)
> {
>    return f(std::forward<T>(t)...);
> }
>
> we will be able to write
>
> template <class ... T>
> void g(T&& ... t)
> {
>    return f(t...);
> }
> Basically, it's an extension to the existing return x; where x is a local
> variable.
>

Your proposed language change has already been made; see
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1579

--

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

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On M=
on, Apr 21, 2014 at 11:13 AM, Mikhail Semenov <span dir=3D"ltr">&lt;<a href=
=3D"mailto:mikhailsemenov1957@gmail.com" target=3D"_blank">mikhailsemenov19=
57@gmail.com</a>&gt;</span> wrote:<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-style:solid;p=
adding-left:1ex"><div dir=3D"ltr"><p>I would like to propose: in a return s=
tatement expression if a local variable (which is not defined as an lvalue =
reference) and occurs only once should be treated as an rvalue.</p>
<p>If this is adopted we won&#39;t have to write forwarding in most cases.<=
/p><p>Instead of writing:</p><p>template &lt;class ... T&gt;<br>void g(T&am=
p;&amp; ... t)<br>{<br>=C2=A0=C2=A0 return f(std::forward&lt;T&gt;(t)...);<=
br>}</p>
<p>we will be able to write</p><p>template &lt;class ... T&gt;<br>void g(T&=
amp;&amp; ... t)<br>{<br>=C2=A0=C2=A0 return f(t...);<br>}</p><div>Basicall=
y, it&#39;s an extension to the existing return x; where x is a local varia=
ble.</div>
</div></blockquote><div><br></div><div>Your proposed language change has al=
ready been made; see <a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs=
/cwg_defects.html#1579">http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_def=
ects.html#1579</a></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 />

--047d7b418c8b9f23ce04f791b899--

.


Author: Christof Meerwald <cmeerw@cmeerw.org>
Date: Mon, 21 Apr 2014 20:43:30 +0200
Raw View
On Mon, Apr 21, 2014 at 11:32:26AM -0700, Richard Smith wrote:
> On Mon, Apr 21, 2014 at 11:13 AM, Mikhail Semenov <
> mikhailsemenov1957@gmail.com> wrote:
> > I would like to propose: in a return statement expression if a local
> > variable (which is not defined as an lvalue reference) and occurs only once
> > should be treated as an rvalue.
[...]
> > we will be able to write
> >
> > template <class ... T>
> > void g(T&& ... t)
> > {
> >    return f(t...);
> > }
> > Basically, it's an extension to the existing return x; where x is a local
> > variable.
>
> Your proposed language change has already been made; see
> http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1579

I don't think that covers what Mikhail is suggesting - I think Mikhail
wants to extend the special treatment of id-expressions to any
sub-expression in a return statement (not just for the case where the
expression is a single id-expression).


Christof

--

http://cmeerw.org                              sip:cmeerw at cmeerw.org
mailto:cmeerw at cmeerw.org                   xmpp:cmeerw at cmeerw.org

--

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

.


Author: Richard Smith <richard@metafoo.co.uk>
Date: Mon, 21 Apr 2014 13:16:16 -0700
Raw View
--001a11334c38f8958904f7932bff
Content-Type: text/plain; charset=UTF-8

On Mon, Apr 21, 2014 at 11:43 AM, Christof Meerwald <cmeerw@cmeerw.org>wrote:

> On Mon, Apr 21, 2014 at 11:32:26AM -0700, Richard Smith wrote:
> > On Mon, Apr 21, 2014 at 11:13 AM, Mikhail Semenov <
> > mikhailsemenov1957@gmail.com> wrote:
> > > I would like to propose: in a return statement expression if a local
> > > variable (which is not defined as an lvalue reference) and occurs only
> once
> > > should be treated as an rvalue.
> [...]
> > > we will be able to write
> > >
> > > template <class ... T>
> > > void g(T&& ... t)
> > > {
> > >    return f(t...);
> > > }
> > > Basically, it's an extension to the existing return x; where x is a
> local
> > > variable.
> >
> > Your proposed language change has already been made; see
> > http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1579
>
> I don't think that covers what Mikhail is suggesting - I think Mikhail
> wants to extend the special treatment of id-expressions to any
> sub-expression in a return statement (not just for the case where the
> expression is a single id-expression).


Oh, I see. No, that's not sound.

T f(std::vector<int> v, int n) {
  int *p = find(v, n);
  return g(p, v); // bad things might happen if 'v' is moved into 'g'.
}

--

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

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On M=
on, Apr 21, 2014 at 11:43 AM, Christof Meerwald <span dir=3D"ltr">&lt;<a hr=
ef=3D"mailto:cmeerw@cmeerw.org" target=3D"_blank">cmeerw@cmeerw.org</a>&gt;=
</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"">On Mon, Apr 21, 2014 at 11:3=
2:26AM -0700, Richard Smith wrote:<br>
&gt; On Mon, Apr 21, 2014 at 11:13 AM, Mikhail Semenov &lt;<br>
&gt; <a href=3D"mailto:mikhailsemenov1957@gmail.com">mikhailsemenov1957@gma=
il.com</a>&gt; wrote:<br>
&gt; &gt; I would like to propose: in a return statement expression if a lo=
cal<br>
&gt; &gt; variable (which is not defined as an lvalue reference) and occurs=
 only once<br>
&gt; &gt; should be treated as an rvalue.<br>
</div>[...]<br>
<div class=3D"">&gt; &gt; we will be able to write<br>
&gt; &gt;<br>
&gt; &gt; template &lt;class ... T&gt;<br>
&gt; &gt; void g(T&amp;&amp; ... t)<br>
&gt; &gt; {<br>
&gt; &gt; =C2=A0 =C2=A0return f(t...);<br>
&gt; &gt; }<br>
&gt; &gt; Basically, it&#39;s an extension to the existing return x; where =
x is a local<br>
&gt; &gt; variable.<br>
&gt;<br>
&gt; Your proposed language change has already been made; see<br>
&gt; <a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.htm=
l#1579" target=3D"_blank">http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_d=
efects.html#1579</a><br>
<br>
</div>I don&#39;t think that covers what Mikhail is suggesting - I think Mi=
khail<br>
wants to extend the special treatment of id-expressions to any<br>
sub-expression in a return statement (not just for the case where the<br>
expression is a single id-expression).</blockquote><div><br></div><div>Oh, =
I see. No, that&#39;s not sound.</div><div><br></div><div>T f(std::vector&l=
t;int&gt; v, int n) {</div><div>=C2=A0 int *p =3D find(v, n);</div><div>=C2=
=A0 return g(p, v); // bad things might happen if &#39;v&#39; is moved into=
 &#39;g&#39;.<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 />

--001a11334c38f8958904f7932bff--

.


Author: Zhihao Yuan <zy@miator.net>
Date: Mon, 21 Apr 2014 16:32:03 -0400
Raw View
On Mon, Apr 21, 2014 at 4:16 PM, Richard Smith <richard@metafoo.co.uk> wrote:
>
> T f(std::vector<int> v, int n) {
>   int *p = find(v, n);
>   return g(p, v); // bad things might happen if 'v' is moved into 'g'.
> }

Mikhail's original post restricted this with "[...] and occurs only once".
But anyhow, I don't like this proposal, because it's anti-intuitive (the
semantics of the same expression varies depends on the times it
appears in a scope).

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

--

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

.


Author: =?UTF-8?Q?David_Rodr=C3=ADguez_Ibeas?= <dibeas@ieee.org>
Date: Mon, 21 Apr 2014 18:07:36 -0400
Raw View
--001a11c2bf6a18b08904f794ba06
Content-Type: text/plain; charset=UTF-8

It can be argued whether the "only once" applied to the uses of the same
name in the 'return' or whether it applies to any other uses of the
variable in the function. Richard's example uses 'v' only "once" in the
return statement.

Although to be honest, what is the issue with the code in Richard's
example? The vector contents being moved won't invalidate the pointer
(unless the iterator does not propagate and it *copies* and the "valid
unspecified state" of the moved from container is to 'clear()' it...)



On Mon, Apr 21, 2014 at 4:32 PM, Zhihao Yuan <zy@miator.net> wrote:

> On Mon, Apr 21, 2014 at 4:16 PM, Richard Smith <richard@metafoo.co.uk>
> wrote:
> >
> > T f(std::vector<int> v, int n) {
> >   int *p = find(v, n);
> >   return g(p, v); // bad things might happen if 'v' is moved into 'g'.
> > }
>
> Mikhail's original post restricted this with "[...] and occurs only once".
> But anyhow, I don't like this proposal, because it's anti-intuitive (the
> semantics of the same expression varies depends on the times it
> appears in a scope).
>
> --
> Zhihao Yuan, ID lichray
> The best way to predict the future is to invent it.
> ___________________________________________________
> 4BSD -- http://4bsd.biz/
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--

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

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

<div dir=3D"ltr">It can be argued whether the &quot;only once&quot; applied=
 to the uses of the same name in the &#39;return&#39; or whether it applies=
 to any other uses of the variable in the function. Richard&#39;s example u=
ses &#39;v&#39; only &quot;once&quot; in the return statement. <br>
<br>Although to be honest, what is the issue with the code in Richard&#39;s=
 example? The vector contents being moved won&#39;t invalidate the pointer =
(unless the iterator does not propagate and it *copies* and the &quot;valid=
 unspecified state&quot; of the moved from container is to &#39;clear()&#39=
; it...)<div>
<br></div></div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quot=
e">On Mon, Apr 21, 2014 at 4:32 PM, Zhihao Yuan <span dir=3D"ltr">&lt;<a hr=
ef=3D"mailto:zy@miator.net" target=3D"_blank">zy@miator.net</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 class=3D"">On Mon, Apr 21, 2014 at 4:16=
 PM, Richard Smith &lt;<a href=3D"mailto:richard@metafoo.co.uk">richard@met=
afoo.co.uk</a>&gt; wrote:<br>

&gt;<br>
&gt; T f(std::vector&lt;int&gt; v, int n) {<br>
&gt; =C2=A0 int *p =3D find(v, n);<br>
&gt; =C2=A0 return g(p, v); // bad things might happen if &#39;v&#39; is mo=
ved into &#39;g&#39;.<br>
&gt; }<br>
<br>
</div>Mikhail&#39;s original post restricted this with &quot;[...] and occu=
rs only once&quot;.<br>
But anyhow, I don&#39;t like this proposal, because it&#39;s anti-intuitive=
 (the<br>
semantics of the same expression varies depends on the times it<br>
appears in a scope).<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
--<br>
Zhihao Yuan, ID lichray<br>
The best way to predict the future is to invent it.<br>
___________________________________________________<br>
4BSD -- <a href=3D"http://4bsd.biz/" target=3D"_blank">http://4bsd.biz/</a>=
<br>
</font></span><div class=3D"HOEnZb"><div class=3D"h5"><br>
--<br>
<br>
---<br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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%2Bunsubscribe@isocpp.org">std-propo=
sals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

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

--001a11c2bf6a18b08904f794ba06--

.


Author: Richard Smith <richard@metafoo.co.uk>
Date: Mon, 21 Apr 2014 15:22:30 -0700
Raw View
--20cf303637316c45a704f794efe9
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Mon, Apr 21, 2014 at 3:07 PM, David Rodr=C3=ADguez Ibeas <dibeas@ieee.or=
g>wrote:

> It can be argued whether the "only once" applied to the uses of the same
> name in the 'return' or whether it applies to any other uses of the
> variable in the function. Richard's example uses 'v' only "once" in the
> return statement.
>
> Although to be honest, what is the issue with the code in Richard's
> example? The vector contents being moved won't invalidate the pointer
> (unless the iterator does not propagate and it *copies* and the "valid
> unspecified state" of the moved from container is to 'clear()' it...)
>

That depends on what 'g' does with its vector. The problem is that this
shortens the effective lifetime of v's value, and there may be local
variables or other subexpressions that depend on 'v' having its full
lifetime.

FWIW, this is a problem even with the relaxations that DR1579 introduced,
but it's a bit harder to see because you need to be in a destructor to
observe it:

struct StringyThing { StringyThing(std::string); };
StringyThing f() {
  std::string blah;
  auto _ =3D scope_guard([&] { std::cout << blah << std::endl; });
  // fill in blah
  return blah;
}

Without DR1579, this will print the computed value of 'blah'. With DR1579,
it could print anything ('blah' is in a valid but unspecified state). The
same problem usually doesn't occur under the C++11 rules in practice,
because in most cases where the copy is promoted to a move, the move is
elided.


> On Mon, Apr 21, 2014 at 4:32 PM, Zhihao Yuan <zy@miator.net> wrote:
>
>> On Mon, Apr 21, 2014 at 4:16 PM, Richard Smith <richard@metafoo.co.uk>
>> wrote:
>> >
>> > T f(std::vector<int> v, int n) {
>> >   int *p =3D find(v, n);
>> >   return g(p, v); // bad things might happen if 'v' is moved into 'g'.
>> > }
>>
>> Mikhail's original post restricted this with "[...] and occurs only once=
".
>> But anyhow, I don't like this proposal, because it's anti-intuitive (the
>> semantics of the same expression varies depends on the times it
>> appears in a scope).
>>
>> --
>> Zhihao Yuan, ID lichray
>> The best way to predict the future is to invent it.
>> ___________________________________________________
>> 4BSD -- http://4bsd.biz/
>>
>> --
>>
>> ---
>> You received this message because you are subscribed to the Google Group=
s
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n
>> 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/.
>

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

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On M=
on, Apr 21, 2014 at 3:07 PM, David Rodr=C3=ADguez Ibeas <span dir=3D"ltr">&=
lt;<a href=3D"mailto:dibeas@ieee.org" target=3D"_blank">dibeas@ieee.org</a>=
&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">It can be argued whether th=
e &quot;only once&quot; applied to the uses of the same name in the &#39;re=
turn&#39; or whether it applies to any other uses of the variable in the fu=
nction. Richard&#39;s example uses &#39;v&#39; only &quot;once&quot; in the=
 return statement. <br>

<br>Although to be honest, what is the issue with the code in Richard&#39;s=
 example? The vector contents being moved won&#39;t invalidate the pointer =
(unless the iterator does not propagate and it *copies* and the &quot;valid=
 unspecified state&quot; of the moved from container is to &#39;clear()&#39=
; it...)</div>
</blockquote><div><br></div><div>That depends on what &#39;g&#39; does with=
 its vector. The problem is that this shortens the effective lifetime of v&=
#39;s value, and there may be local variables or other subexpressions that =
depend on &#39;v&#39; having its full lifetime.</div>
<div><br></div><div>FWIW, this is a problem even with the relaxations that =
DR1579 introduced, but it&#39;s a bit harder to see because you need to be =
in a destructor to observe it:</div><div><br></div><div>struct StringyThing=
 { StringyThing(std::string); };</div>
<div>StringyThing f() {</div><div>=C2=A0 std::string blah;</div><div>=C2=A0=
 auto _ =3D scope_guard([&amp;] { std::cout &lt;&lt; blah &lt;&lt; std::end=
l; });</div><div>=C2=A0 // fill in blah</div><div>=C2=A0 return blah;</div>=
<div>}</div><div><br>
</div><div>Without DR1579, this will print the computed value of &#39;blah&=
#39;. With DR1579, it could print anything (&#39;blah&#39; is in a valid bu=
t unspecified state). The same problem usually doesn&#39;t occur under the =
C++11 rules in practice, because in most cases where the copy is promoted t=
o a move, the move is elided.</div>
<div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex"><div class=3D"HOEnZb"><div =
class=3D"h5"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On Mon, =
Apr 21, 2014 at 4:32 PM, Zhihao Yuan <span dir=3D"ltr">&lt;<a href=3D"mailt=
o:zy@miator.net" target=3D"_blank">zy@miator.net</a>&gt;</span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div>On Mon, Apr 21, 2014 at 4:16 PM, Richar=
d Smith &lt;<a href=3D"mailto:richard@metafoo.co.uk" target=3D"_blank">rich=
ard@metafoo.co.uk</a>&gt; wrote:<br>


&gt;<br>
&gt; T f(std::vector&lt;int&gt; v, int n) {<br>
&gt; =C2=A0 int *p =3D find(v, n);<br>
&gt; =C2=A0 return g(p, v); // bad things might happen if &#39;v&#39; is mo=
ved into &#39;g&#39;.<br>
&gt; }<br>
<br>
</div>Mikhail&#39;s original post restricted this with &quot;[...] and occu=
rs only once&quot;.<br>
But anyhow, I don&#39;t like this proposal, because it&#39;s anti-intuitive=
 (the<br>
semantics of the same expression varies depends on the times it<br>
appears in a scope).<br>
<span><font color=3D"#888888"><br>
--<br>
Zhihao Yuan, ID lichray<br>
The best way to predict the future is to invent it.<br>
___________________________________________________<br>
4BSD -- <a href=3D"http://4bsd.biz/" target=3D"_blank">http://4bsd.biz/</a>=
<br>
</font></span><div><div><br>
--<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%2Bunsubscribe@isocpp.org" target=3D=
"_blank">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">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" target=3D"_=
blank">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">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></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 />

--20cf303637316c45a704f794efe9--

.


Author: Mikhail Semenov <mikhailsemenov1957@gmail.com>
Date: Tue, 22 Apr 2014 02:46:08 -0700 (PDT)
Raw View
------=_Part_793_30346457.1398159968386
Content-Type: text/plain; charset=UTF-8


>
> That depends on what 'g' does with its vector. The problem is that this
> shortens the effective lifetime of v's value, and there may be local
> variables or other subexpressions that depend on 'v' having its full
> lifetime.
>
OK, my last effort for defence. Obviously,
in certain cases there can be a difference between

*return g(n,v);*

and

*auto x = g(n,v);*
*return x;*

But my point is it can be beneficial.



--

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

<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px=
 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); borde=
r-left-width: 1px; border-left-style: solid;"><div dir=3D"ltr"><div><font c=
olor=3D"#0000ff">That depends on what 'g' does with its vector. The problem=
 is that this shortens the effective lifetime of v's value, and there may b=
e local variables or other subexpressions that depend on 'v' having its ful=
l lifetime.<br></font></div></div></blockquote><div>OK, my last effort for =
defence. Obviously,</div><div>in certain cases there can be a difference be=
tween </div><div><strong></strong>&nbsp;</div><div><strong>return g(n,v);</=
strong></div><div>&nbsp;</div><div>and</div><div><strong></strong>&nbsp;</d=
iv><div><strong>auto x =3D g(n,v);</strong></div><div><strong>return x;</st=
rong></div><div>&nbsp;</div><div>But my point is&nbsp;it can be beneficial.=
</div><div>&nbsp;</div><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_793_30346457.1398159968386--

.