------=_Part_1896_452935924.1527110829989
Content-Type: multipart/alternative;
 boundary="----=_Part_1897_1957470986.1527110829990"

------=_Part_1897_1957470986.1527110829990
Content-Type: text/plain; charset="UTF-8"



In my opinion, code such as the following should never be allowed to
compile.

auto it = std::vector<int>{5,4,3,2,1}.begin();

The iterator, in this example, references an object whose lifetime has
ended. It compiles, but you should not use the iterator provided.

I don't expect people to actually write such code but it is perfectly
possible to have this occur inside heavily templated code and easily go
unnoticed. We can make this uncompilable via explicit deletion of the
rvalue ref-qualified version of begin() while keeping the lvalue
ref-qualified as is. At this point I hope most readers to find this a
reasonable idea (or else my eyes will be opened by some wize and knowledgeable
person's reply).

In general all type's in standard library whose non static member functions
expose any sort of handle to its internal state should have either its
rvalue ref-qualified implementation deleted or provided an implementation
that does a value copy/move or other appropriate exposure of the internal
state of the rvalue. Yet, at this point I need a C++ language lawyer to
tell me if this is possibly is a non starter. At the moment I'm not certain
on the exact behavior for what the language says about temporary object's
lifetime extension. I know what I can observe what the compilers are doing,
but I want to double check what the language says. In the following is the
temporary vector's lifetime extended, if so why?

somefunction(std::vector<int>{5,4,3,2,1}.begin());

If it is the case that lifetime is extended, then we currently have no
mechanism to distinguish methods on rvalue's vs rvalues which have extended
lifetime. In that case I'd additionally propose an extra special rvalue
ref-qualification to cover this case or to be treated as lvalue in this
context. Or some wize and knowledgeable person can explain why either would
not work.

tldr; I believe that library authors should have the right language
features they need to prevent client code having accidental access to
internal state of temporary objects. That language feature (what ever it
may be) should be applied to the standard library.

Gareth Lloyd

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/f3abea5e-9d3a-407f-be79-48cc5cfd3ddc%40isocpp.org.

------=_Part_1897_1957470986.1527110829990
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">
<table title=3D"data storage" width=3D"100%" cellspacing=3D"0" cellpadding=
=3D"0" border=3D"0"><tbody><tr><td width=3D"0" height=3D"0">
<form method=3D"post" action=3D"ssrv.cgi" lang=3D"en_US">





































</form><br></td><td width=3D"0" height=3D"0">
<table width=3D"100%" cellspacing=3D"0" cellpadding=3D"5" border=3D"0">
 <tbody><tr>
  <td class=3D"midtext">In my opinion, code such as the following should ne=
ver be allowed to compile.=C2=A0<br>=C2=A0<br>auto it =3D std::vector&lt;in=
t&gt;{5,4,3,2,1}.begin();=C2=A0<br>=C2=A0<br>The iterator, in this example,=
 references an object whose lifetime has ended. It compiles, but you should=
 not use the iterator provided.<br>=C2=A0<br>I
 don&#39;t expect people to actually write such code but it is perfectly=20
possible to have this occur inside heavily templated code and easily go=20
unnoticed. We can make this uncompilable via explicit deletion of the=20
rvalue ref-qualified version of begin() while keeping the lvalue=20
ref-qualified as is. At this point I hope most readers to find this
 a reasonable idea (or else my eyes will be opened by some wize and <span d=
ata-dobid=3D"hdw">knowledgeable </span>person&#39;s reply).<br>=C2=A0<br>In=
 general all type&#39;s in standard library=20
whose non static member functions expose any sort of handle to its=20
internal state should have either its rvalue ref-qualified implementation=
=20
deleted or provided an implementation that does a value copy/move or other=
=20
appropriate exposure of the internal state of the rvalue. Yet, at this poin=
t I need=20
a C++ language lawyer to tell me if this is possibly is a non starter. At=
=20
the moment I&#39;m not certain on the exact behavior for what the language =
says about temporary object&#39;s lifetime extension. I know what I can obs=
erve what the compilers are doing, but I want to double check what the lang=
uage says. In the following is the temporary
 vector&#39;s lifetime extended, if so why?=C2=A0<br>=C2=A0<br>somefunction=
(std::vector&lt;int&gt;{5,4,3,2,1}.begin());=C2=A0<br>=C2=A0<br>If
 it is the case that lifetime is extended, then we currently have no=20
mechanism to distinguish methods on rvalue&#39;s vs rvalues which have=20
extended lifetime. In that case I&#39;d additionally propose an extra=20
special rvalue ref-qualification to cover this case or to be treated as lva=
lue in this context. Or some wize and <span data-dobid=3D"hdw">knowledgeabl=
e </span>person can explain why either would not work.<br>=C2=A0<br>tldr; I=
 believe that library authors should have the right language features they =
need to prevent client code having accidental access to internal state of t=
emporary objects. That language feature (what ever it may be) should be app=
lied to the standard library.<br><br>Gareth Lloyd</td></tr></tbody></table>=
</td></tr></tbody></table><font size=3D"-3" face=3D"verdana"></font>
<form method=3D"post" action=3D"ssrv.cgi" target=3D"navbar" lang=3D"en_US">=
</form>

</div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/f3abea5e-9d3a-407f-be79-48cc5cfd3ddc%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/f3abea5e-9d3a-407f-be79-48cc5cfd3ddc=
%40isocpp.org</a>.<br />

------=_Part_1897_1957470986.1527110829990--

------=_Part_1896_452935924.1527110829989--

.

--0000000000008768e9056ce6781f
Content-Type: text/plain; charset="UTF-8"

On Wed, May 23, 2018 at 5:27 PM Gareth Lloyd <gareth@ignition-web.co.uk>
wrote:

> In general all type's in standard library whose non static member
> functions expose any sort of handle to its internal state should have
> either its rvalue ref-qualified implementation deleted or provided an
> implementation that does a value copy/move or other appropriate exposure of
> the internal state of the rvalue.
>

Your assumption is that these objects are being used after the object is
destroyed, but that is not necessarily the case. In general, the deletion
of rvalue reference overloads of functions (or, somewhat equivalently, the
deletion of rvalue-reference-qualified-member-functions), is
subtly-different from what is truly desired. In the case of begin(),
deleting the && overload is less-likely to prevent valid uses, since you
*usually* need both a begin and an end, but really I'd rather we have a
more precise solution to the problem.

On Wed, May 23, 2018 at 5:27 PM Gareth Lloyd <gareth@ignition-web.co.uk>
wrote:

> Yet, at this point I need a C++ language lawyer to tell me if this is
> possibly is a non starter. At the moment I'm not certain on the exact
> behavior for what the language says about temporary object's lifetime
> extension. I know what I can observe what the compilers are doing, but I
> want to double check what the language says. In the following is the
> temporary vector's lifetime extended, if so why?
>
> somefunction(std::vector<int>{5,4,3,2,1}.begin());
>

There is no lifetime extension required in that example. Temporaries always
survive until the end of the full expression that they are a part of.

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANh8DEnPS%2BFMpWpAp1WLe-9H1twSc30w7bQph_MgBMK0FM0t8A%40mail.gmail.com.

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

<div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr">On Wed, May 23=
, 2018 at 5:27 PM Gareth Lloyd &lt;<a href=3D"mailto:gareth@ignition-web.co=
..uk">gareth@ignition-web.co.uk</a>&gt; wrote:=C2=A0<br></div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;p=
adding-left:1ex"><div dir=3D"ltr"><table title=3D"data storage" width=3D"10=
0%" cellspacing=3D"0" cellpadding=3D"0" border=3D"0"><tbody><tr><td width=
=3D"0" height=3D"0"><table width=3D"100%" cellspacing=3D"0" cellpadding=3D"=
5" border=3D"0"><tbody><tr><td class=3D"m_-4732282293342502264midtext">In g=
eneral all type&#39;s in standard library=20
whose non static member functions expose any sort of handle to its=20
internal state should have either its rvalue ref-qualified implementation=
=20
deleted or provided an implementation that does a value copy/move or other=
=20
appropriate exposure of the internal state of the rvalue.</td></tr></tbody>=
</table></td></tr></tbody></table></div></blockquote><div><br></div><div>Yo=
ur assumption is that these objects are being used after the object is dest=
royed, but that is not necessarily the case. In general, the deletion of rv=
alue reference overloads of functions (or, somewhat equivalently, the delet=
ion of rvalue-reference-qualified-member-functions), is subtly-different fr=
om what is truly desired. In the case of begin(), deleting the &amp;&amp; o=
verload is less-likely to prevent valid uses, since you *usually* need both=
 a begin and an end, but really I&#39;d rather we have a more precise solut=
ion to the problem.</div><div><br></div><div><span style=3D"color:rgb(34,34=
,34);font-family:sans-serif;font-size:13px;font-style:normal;font-variant-l=
igatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:nor=
mal;text-align:start;text-indent:0px;text-transform:none;white-space:normal=
;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:i=
nitial;text-decoration-color:initial;float:none;display:inline">On Wed, May=
 23, 2018 at 5:27 PM Gareth Lloyd &lt;<a href=3D"mailto:gareth@ignition-web=
..co.uk">gareth@ignition-web.co.uk</a>&gt; wrote:</span>=C2=A0</div><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><div dir=3D"ltr"><table title=3D"data storage" width=
=3D"100%" cellspacing=3D"0" cellpadding=3D"0" border=3D"0"><tbody><tr><td w=
idth=3D"0" height=3D"0"><table width=3D"100%" cellspacing=3D"0" cellpadding=
=3D"5" border=3D"0"><tbody><tr><td class=3D"m_-4732282293342502264midtext">=
Yet, at this point I need=20
a C++ language lawyer to tell me if this is possibly is a non starter. At=
=20
the moment I&#39;m not certain on the exact behavior for what the language =
says about temporary object&#39;s lifetime extension. I know what I can obs=
erve what the compilers are doing, but I want to double check what the lang=
uage says. In the following is the temporary
 vector&#39;s lifetime extended, if so why?=C2=A0<br>=C2=A0<br>somefunction=
(std::vector&lt;int&gt;{5,4,3,2,1}.begin());=C2=A0<br></td></tr></tbody></t=
able></td></tr></tbody></table></div></blockquote><div><br></div><div>There=
 is no lifetime extension required in that example. Temporaries always surv=
ive until the end of the full expression that they are a part of.</div></di=
v></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CANh8DEnPS%2BFMpWpAp1WLe-9H1twSc30w7b=
Qph_MgBMK0FM0t8A%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANh8DEnPS%2BFM=
pWpAp1WLe-9H1twSc30w7bQph_MgBMK0FM0t8A%40mail.gmail.com</a>.<br />

--0000000000008768e9056ce6781f--

.

------=_Part_10007_1285946117.1527201468574
Content-Type: multipart/alternative;
 boundary="----=_Part_10008_706362632.1527201468574"

------=_Part_10008_706362632.1527201468574
Content-Type: text/plain; charset="UTF-8"



Thank you Matt, I think I have a better handle on this now.

I suppose a more precise solution would involve introducing a new attribute
such as [[lifetime_dependent_return]].

[[lifetime_dependent_return]] would express that the returned value given
by the method is only valid while the object which created it or it depends
upon is still materialized. Any methods called upon that dependent value
which are also attributed with [[lifetime_dependent_return]] would
propagate the lifetime dependency of the original object; methods without
this attribute break the dependency chain. If an unbroken dependency chain
is made, the compiler will enforce the value must be discarded if the
dependent object is to be destroyed at the end of the expression.

template <typename T>
[[lifetime_dependent_return]] iterator begin();

auto it = std::vector<int>{5,4,3,2,1}.begin(); // compiler error

struct example {
    [[lifetime_dependent_return]] example& dependent() { teturn *this; }
    example not_dependent() { teturn *this; }
};

auto e1 = example{}.dependent().dependent().dependent(); \\ compile error
auto e2 = example{}.dependent().not_dependent().dependent(); \\ compile
error
auto e3 = example{}.dependent().dependent().not_dependent(); \\ fine

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/81b39e17-fe78-41ab-b9c9-3b830e32dbf5%40isocpp.org.

------=_Part_10008_706362632.1527201468574
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">
<table title=3D"data storage" width=3D"100%" cellspacing=3D"0" cellpadding=
=3D"0" border=3D"0"><tbody><tr><td width=3D"0" height=3D"0">
<form method=3D"post" action=3D"ssrv.cgi" lang=3D"en_US">





































</form><br></td><td width=3D"0" height=3D"0">
<table width=3D"100%" cellspacing=3D"0" cellpadding=3D"5" border=3D"0">
 <tbody><tr>
  <td class=3D"midtext">Thank you Matt, I think I have a better handle on t=
his now.=C2=A0<br>=C2=A0<br>I suppose a more precise solution would involve=
 introducing a new attribute such as [[lifetime_dependent_return]].=C2=A0<b=
r>=C2=A0<br>[[lifetime_dependent_return]]
 would express that the returned value given by the method is only valid wh=
ile the object which created it or it depends upon is still materialized. A=
ny methods=20
called upon that dependent value which are also attributed with=20
[[lifetime_dependent_return]] would propagate the lifetime dependency of
 the original object; methods without this attribute break the=20
dependency chain. If an unbroken dependency chain is made, the compiler=20
will enforce the value must be discarded if the dependent object is to=20
be destroyed at the end of the expression.<br><br></td></tr></tbody></table=
></td></tr></tbody></table><div>template &lt;typename T&gt;<br></div><div>[=
[lifetime_dependent_return]] <span class=3D"mw-geshi cpp source-cpp">iterat=
or begin<span class=3D"br0">(</span><span class=3D"br0">)</span><span class=
=3D"sy4">;</span></span></div><div><span class=3D"mw-geshi cpp source-cpp">=
<span class=3D"sy4"></span></span><br><span class=3D"mw-geshi cpp source-cp=
p"><span class=3D"sy4">auto it =3D std::vector&lt;int&gt;{5,4,3,2,1}.begin(=
); // compiler error<br></span></span><table width=3D"100%" cellspacing=3D"=
0" cellpadding=3D"5" border=3D"0"><tbody><tr><td><br></td></tr></tbody></ta=
ble></div><div><span class=3D"mw-geshi cpp source-cpp"><span class=3D"sy4">=
struct example {</span><span class=3D"sy4"></span></span><br><span class=3D=
"mw-geshi cpp source-cpp"><span class=3D"sy4"><span class=3D"mw-geshi cpp s=
ource-cpp"><span class=3D"sy4">=C2=A0=C2=A0=C2=A0 [[lifetime_dependent_retu=
rn]] example&amp; dependent() { teturn *this; }</span></span></span></span>=
<br><span class=3D"mw-geshi cpp source-cpp"><span class=3D"sy4"><span class=
=3D"mw-geshi cpp source-cpp"><span class=3D"sy4"><span class=3D"mw-geshi cp=
p source-cpp"><span class=3D"sy4">=C2=A0=C2=A0=C2=A0 example not_dependent(=
) { teturn *this; }</span></span></span></span></span></span></div><div><sp=
an class=3D"mw-geshi cpp source-cpp"><span class=3D"sy4">};<br></span></spa=
n></div><div><span class=3D"mw-geshi cpp source-cpp"><span class=3D"sy4"><b=
r></span></span></div><div><span class=3D"mw-geshi cpp source-cpp"><span cl=
ass=3D"sy4">auto e1 =3D </span></span><span class=3D"mw-geshi cpp source-cp=
p"><span class=3D"sy4"><span class=3D"mw-geshi cpp source-cpp"><span class=
=3D"sy4">example{}</span></span></span></span><span class=3D"mw-geshi cpp s=
ource-cpp"><span class=3D"sy4"><span class=3D"mw-geshi cpp source-cpp"><spa=
n class=3D"sy4">.</span></span></span></span><span class=3D"mw-geshi cpp so=
urce-cpp"><span class=3D"sy4"><span class=3D"mw-geshi cpp source-cpp"><span=
 class=3D"sy4">dependent()</span></span></span></span><span class=3D"mw-ges=
hi cpp source-cpp"><span class=3D"sy4"><span class=3D"mw-geshi cpp source-c=
pp"><span class=3D"sy4">.</span></span></span></span><span class=3D"mw-gesh=
i cpp source-cpp"><span class=3D"sy4"><span class=3D"mw-geshi cpp source-cp=
p"><span class=3D"sy4">dependent()</span></span></span></span><span class=
=3D"mw-geshi cpp source-cpp"><span class=3D"sy4"><span class=3D"mw-geshi cp=
p source-cpp"><span class=3D"sy4">.</span></span></span></span><span class=
=3D"mw-geshi cpp source-cpp"><span class=3D"sy4"><span class=3D"mw-geshi cp=
p source-cpp"><span class=3D"sy4">dependent(); \\ compile error</span></spa=
n></span></span></div><div><span class=3D"mw-geshi cpp source-cpp"><span cl=
ass=3D"sy4">auto e2 =3D </span></span><span class=3D"mw-geshi cpp source-cp=
p"><span class=3D"sy4"><span class=3D"mw-geshi cpp source-cpp"><span class=
=3D"sy4">example{}</span></span></span></span><span class=3D"mw-geshi cpp s=
ource-cpp"><span class=3D"sy4"><span class=3D"mw-geshi cpp source-cpp"><spa=
n class=3D"sy4">.</span></span></span></span><span class=3D"mw-geshi cpp so=
urce-cpp"><span class=3D"sy4"><span class=3D"mw-geshi cpp source-cpp"><span=
 class=3D"sy4">dependent()</span></span></span></span><span class=3D"mw-ges=
hi cpp source-cpp"><span class=3D"sy4"><span class=3D"mw-geshi cpp source-c=
pp"><span class=3D"sy4">.</span></span></span></span><span class=3D"mw-gesh=
i cpp source-cpp"><span class=3D"sy4"><span class=3D"mw-geshi cpp source-cp=
p"><span class=3D"sy4"><span class=3D"mw-geshi cpp source-cpp"><span class=
=3D"sy4">not_dependent</span></span></span></span></span></span><span class=
=3D"mw-geshi cpp source-cpp"><span class=3D"sy4"><span class=3D"mw-geshi cp=
p source-cpp"><span class=3D"sy4">()</span></span></span></span><span class=
=3D"mw-geshi cpp source-cpp"><span class=3D"sy4"><span class=3D"mw-geshi cp=
p source-cpp"><span class=3D"sy4">.</span></span></span></span><span class=
=3D"mw-geshi cpp source-cpp"><span class=3D"sy4"><span class=3D"mw-geshi cp=
p source-cpp"><span class=3D"sy4">dependent(); \\ compile error</span></spa=
n></span></span></div><div><span class=3D"mw-geshi cpp source-cpp"><span cl=
ass=3D"sy4">auto e3 =3D </span></span><span class=3D"mw-geshi cpp source-cp=
p"><span class=3D"sy4"><span class=3D"mw-geshi cpp source-cpp"><span class=
=3D"sy4">example{}</span></span></span></span><span class=3D"mw-geshi cpp s=
ource-cpp"><span class=3D"sy4"><span class=3D"mw-geshi cpp source-cpp"><spa=
n class=3D"sy4">.</span></span></span></span><span class=3D"mw-geshi cpp so=
urce-cpp"><span class=3D"sy4"><span class=3D"mw-geshi cpp source-cpp"><span=
 class=3D"sy4">dependent()</span></span></span></span><span class=3D"mw-ges=
hi cpp source-cpp"><span class=3D"sy4"><span class=3D"mw-geshi cpp source-c=
pp"><span class=3D"sy4">.</span></span></span></span><span class=3D"mw-gesh=
i cpp source-cpp"><span class=3D"sy4"><span class=3D"mw-geshi cpp source-cp=
p"><span class=3D"sy4">dependent()</span></span></span></span><span class=
=3D"mw-geshi cpp source-cpp"><span class=3D"sy4"><span class=3D"mw-geshi cp=
p source-cpp"><span class=3D"sy4">.</span></span></span></span><span class=
=3D"mw-geshi cpp source-cpp"><span class=3D"sy4"><span class=3D"mw-geshi cp=
p source-cpp"><span class=3D"sy4"><span class=3D"mw-geshi cpp source-cpp"><=
span class=3D"sy4">not_dependent</span></span></span></span></span></span><=
span class=3D"mw-geshi cpp source-cpp"><span class=3D"sy4"><span class=3D"m=
w-geshi cpp source-cpp"><span class=3D"sy4">(); \\ fine</span></span></span=
></span><br><span class=3D"mw-geshi cpp source-cpp"><span class=3D"sy4"><sp=
an class=3D"mw-geshi cpp source-cpp"><span class=3D"sy4"></span></span></sp=
an></span><span class=3D"mw-geshi cpp source-cpp"><span class=3D"sy4"><span=
 class=3D"mw-geshi cpp source-cpp"><span class=3D"sy4"></span></span></span=
></span><span class=3D"mw-geshi cpp source-cpp"><span class=3D"sy4"><span c=
lass=3D"mw-geshi cpp source-cpp"><span class=3D"sy4"></span></span></span><=
/span></div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/81b39e17-fe78-41ab-b9c9-3b830e32dbf5%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/81b39e17-fe78-41ab-b9c9-3b830e32dbf5=
%40isocpp.org</a>.<br />

------=_Part_10008_706362632.1527201468574--

------=_Part_10007_1285946117.1527201468574--

.

------=_Part_9727_2043010048.1527202128598
Content-Type: multipart/alternative;
 boundary="----=_Part_9728_79512115.1527202128599"

------=_Part_9728_79512115.1527202128599
Content-Type: text/plain; charset="UTF-8"

My example which returned references should be ok as they cause a copy on
assignment, which is a way of breaking the dependency chain. Bellow is a
corrected example.

auto e1 = example{}.dependent().dependent().dependent(); \\ fine
auto e2 = example{}.dependent().not_dependent().dependent(); \\ fine
auto e3 = example{}.dependent().dependent().not_dependent(); \\ fine

decltype(auto) e4 = example{}.dependent().dependent().dependent(); \\ compile
error
decltype(auto) e5 = example{}.dependent().not_dependent().dependent(); \\ compile
error
decltype(auto) e6 = example{}.dependent().dependent().not_dependent(); \\
fine

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/a77b6fa8-985a-4d79-a53a-28f2602733b3%40isocpp.org.

------=_Part_9728_79512115.1527202128599
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><span><span>M</span></span><span><span><span><span><s=
pan><span>y example which returned references should be ok as they cause a =
copy on assignment, which is a way of breaking the dependency chain. Bellow=
 is a corrected example.<br></span></span></span></span></span></span></div=
><div><span><span><br></span></span></div><div><span><span>auto e1 =3D </sp=
an></span><span><span><span><span>example{}</span></span></span></span><spa=
n><span><span><span>.</span></span></span></span><span><span><span><span>de=
pendent()</span></span></span></span><span><span><span><span>.</span></span=
></span></span><span><span><span><span>dependen<wbr>t()</span></span></span=
></span><span><span><span><span>.</span></span></span></span><span><span><s=
pan><span>dependent(); \\ fine</span></span></span></span></div><div><span>=
<span>auto e2 =3D </span></span><span><span><span><span>example{}</span></s=
pan></span></span><span><span><span><span>.</span></span></span></span><spa=
n><span><span><span>dependent()</span></span></span></span><span><span><spa=
n><span>.</span></span></span></span><span><span><span><span><span><span>no=
t_<wbr>dependent</span></span></span></span></span></span><span><span><span=
><span>()</span></span></span></span><span><span><span><span>.</span></span=
></span></span><span><span><span><span>dependent(); \\ fine</span></span></=
span></span></div><div><span><span>auto e3 =3D </span></span><span><span><s=
pan><span>example{}</span></span></span></span><span><span><span><span>.</s=
pan></span></span></span><span><span><span><span>dependent()</span></span><=
/span></span><span><span><span><span>.</span></span></span></span><span><sp=
an><span><span>dependen<wbr>t()</span></span></span></span><span><span><spa=
n><span>.</span></span></span></span><span><span><span><span><span><span>no=
t_dependent</span></span></span></span></span></span><span><span><span><spa=
n>(); \\ fine</span></span></span></span></div><div><br></div><div><div><sp=
an><span>decltype(auto) e4 =3D </span></span><span><span><span><span>exampl=
e{}</span></span></span></span><span><span><span><span>.</span></span></spa=
n></span><span><span><span><span>dependent()</span></span></span></span><sp=
an><span><span><span>.</span></span></span></span><span><span><span><span>d=
ependen<wbr>t()</span></span></span></span><span><span><span><span>.</span>=
</span></span></span><span><span><span><span>dependent(); \\ </span></span>=
</span></span><span><span><span><span>compile error</span></span></span></s=
pan></div><div><span><span>decltype(auto) </span></span><span><span>e5 =3D =
</span></span><span><span><span><span>example{}</span></span></span></span>=
<span><span><span><span>.</span></span></span></span><span><span><span><spa=
n>dependent()</span></span></span></span><span><span><span><span>.</span></=
span></span></span><span><span><span><span><span><span>not_<wbr>dependent</=
span></span></span></span></span></span><span><span><span><span>()</span></=
span></span></span><span><span><span><span>.</span></span></span></span><sp=
an><span><span><span>dependent(); \\ </span></span></span></span><span><spa=
n><span><span>compile error</span></span></span></span></div><span><span>de=
cltype(auto) </span></span><span><span>e6 =3D </span></span><span><span><sp=
an><span>example{}</span></span></span></span><span><span><span><span>.</sp=
an></span></span></span><span><span><span><span>dependent()</span></span></=
span></span><span><span><span><span>.</span></span></span></span><span><spa=
n><span><span>dependen<wbr>t()</span></span></span></span><span><span><span=
><span>.</span></span></span></span><span><span><span><span><span><span>not=
_dependent</span></span></span></span></span></span><span><span><span><span=
>(); \\ fine</span></span></span></span><br><span><span><span><span></span>=
</span></span></span><span><span><span><span></span></span></span></span></=
div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/a77b6fa8-985a-4d79-a53a-28f2602733b3%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/a77b6fa8-985a-4d79-a53a-28f2602733b3=
%40isocpp.org</a>.<br />

------=_Part_9728_79512115.1527202128599--

------=_Part_9727_2043010048.1527202128598--

.

------=_Part_11735_788702426.1527231056146
Content-Type: multipart/alternative;
 boundary="----=_Part_11736_1471265727.1527231056146"

------=_Part_11736_1471265727.1527231056146
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Il giorno venerd=C3=AC 25 maggio 2018 00:37:48 UTC+2, Gareth Lloyd ha scrit=
to:
>
>
>
> I suppose a more precise solution would involve introducing a new=20
> attribute such as [[lifetime_dependent_return]].=20
> =20
>

I agree that having a way to have a function call extend the lifetime of=20
one of its arguments is better approach. The idea is not novel and has been=
=20
discussed before, actually, both in this group (for instance here=20
<https://groups.google.com/a/isocpp.org/d/topic/std-proposals/F35sNst-7DM/d=
iscussion>and=20
here=20
<https://groups.google.com/a/isocpp.org/d/topic/std-proposals/gtxk1xihqcs/d=
iscussion>)=20
and formally (here <http://wg21.link/P0577>). The problem is real and it's=
=20
a big issue with the Ranges library that tends to create a lot of=20
temporaries in expressions that are used as a for-range-initializer in=20
range-based for loops. That said, your suggestion is bad for two reasons:

1) core guidelines says that it should always be possible to ignore=20
attributes completely without significant changes the program behaviour. In=
=20
this case we *do not* want the extension of the lifetime of an object to be=
=20
"ignorable", so we definitely need a syntax that doesn't rely on attributes=
..

2) your proposal covers only member functions, but we have the same issue=
=20
for regular functions. Think about function begin(x), which shares the same=
=20
fate as x.begin().

If I may give you an advice, I suggest you do more research and possibly=20
join forces with whoever is already working on the subject.

PS: in your OP, you suggested to provide deleted version of &&=20
ref-qualified members. That isn't necessary. In fact writing

    Type fun() &;

is just as good as:

    Type fun() &;
    Type fun() && =3D delete;

in the sense that temp().fun() will not compile in both cases, the only=20
difference is in the error message.

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/709f2ceb-5059-4217-8475-288a8f4ecd44%40isocpp.or=
g.

------=_Part_11736_1471265727.1527231056146
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Il giorno venerd=C3=AC 25 maggio 2018 00:37:48 UTC+2, Gare=
th Lloyd ha scritto:<blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr">
<table title=3D"data storage" width=3D"100%" cellspacing=3D"0" cellpadding=
=3D"0" border=3D"0"><tbody><tr><td width=3D"0" height=3D"0">
<form method=3D"post" action=3D"http://ssrv.cgi" target=3D"_blank" onsubmit=
=3D"try {return window.confirm(&quot;Stai inviando informazioni a una pagin=
a esterna. Continuare?&quot;);} catch (e) {return false;}" lang=3D"en_US">





































</form><br></td><td width=3D"0" height=3D"0">
<table width=3D"100%" cellspacing=3D"0" cellpadding=3D"5" border=3D"0">
 <tbody><tr>
  <td><br>I suppose a more precise solution would involve introducing a new=
 attribute such as [[lifetime_dependent_return]].<wbr>=C2=A0<br>=C2=A0<br><=
/td></tr></tbody></table></td></tr></tbody></table><div><span><span><span><=
span></span></span></span></span></div></div></blockquote><div><br></div><d=
iv>I agree that having a way to have a function call extend the lifetime of=
 one of its arguments is better approach. The idea is not novel and has bee=
n discussed before, actually, both in this group (for instance <a href=3D"h=
ttps://groups.google.com/a/isocpp.org/d/topic/std-proposals/F35sNst-7DM/dis=
cussion">here </a>and <a href=3D"https://groups.google.com/a/isocpp.org/d/t=
opic/std-proposals/gtxk1xihqcs/discussion">here</a>) and formally (<a href=
=3D"http://wg21.link/P0577">here</a>). The problem is real and it&#39;s a b=
ig issue with the Ranges library that tends to create a lot of temporaries =
in expressions that are used as a for-range-initializer in range-based for =
loops. That said, your suggestion is bad for two reasons:</div><div><br></d=
iv><div>1) core guidelines says that it should always be possible to ignore=
 attributes completely without significant changes the program behaviour. I=
n this case we *do not* want the extension of the lifetime of an object to =
be &quot;ignorable&quot;, so we definitely need a syntax that doesn&#39;t r=
ely on attributes.</div><div><br></div><div>2) your proposal covers only me=
mber functions, but we have the same issue for regular functions. Think abo=
ut function begin(x), which shares the same fate as x.begin().</div><div><b=
r></div><div>If I may give you an advice, I suggest you do more research an=
d possibly join forces with whoever is already working on the subject.</div=
><div><br></div><div>PS: in your OP, you suggested to provide deleted versi=
on of &amp;&amp; ref-qualified members. That isn&#39;t necessary. In fact w=
riting</div><div><br></div><div>=C2=A0=C2=A0=C2=A0 Type fun() &amp;;</div><=
div><br></div><div>is just as good as:</div><div><br></div><div><div>=C2=A0=
=C2=A0=C2=A0 Type fun() &amp;;</div><div><div>=C2=A0=C2=A0=C2=A0 Type fun()=
 &amp;&amp; =3D delete;</div><div><br></div><div>in the sense that temp().f=
un() will not compile in both cases, the only difference is in the error me=
ssage.<br></div><div><br></div></div></div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/709f2ceb-5059-4217-8475-288a8f4ecd44%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/709f2ceb-5059-4217-8475-288a8f4ecd44=
%40isocpp.org</a>.<br />

------=_Part_11736_1471265727.1527231056146--

------=_Part_11735_788702426.1527231056146--

.

------=_Part_12305_2146077590.1527238198923
Content-Type: multipart/alternative;
 boundary="----=_Part_12306_1672093625.1527238198923"

------=_Part_12306_1672093625.1527238198923
Content-Type: text/plain; charset="UTF-8"

There is yet another proposal to handle lifetime propagation:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0936r0.pdf
I prefer P0936 over P0577 as it is completely transparent at the call site.

Do any of you know if P0936 has been discussed? If so, what was the outcome?

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/48ae754e-18c0-4350-922b-8b6faac0df16%40isocpp.org.

------=_Part_12306_1672093625.1527238198923
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">There is yet another proposal to handle lifetime propagati=
on: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0936r0.pdf<br>=
I prefer P0936 over P0577 as it is completely transparent at the call site.=
<br><br>Do any of you know if P0936 has been discussed? If so, what was the=
 outcome?<br></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/48ae754e-18c0-4350-922b-8b6faac0df16%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/48ae754e-18c0-4350-922b-8b6faac0df16=
%40isocpp.org</a>.<br />

------=_Part_12306_1672093625.1527238198923--

------=_Part_12305_2146077590.1527238198923--

.

------=_Part_12436_226214818.1527238919035
Content-Type: multipart/alternative;
 boundary="----=_Part_12437_558140072.1527238919036"

------=_Part_12437_558140072.1527238919036
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Il giorno venerd=C3=AC 25 maggio 2018 10:49:59 UTC+2, floria...@gmail.com h=
a=20
scritto:
>
> There is yet another proposal to handle lifetime propagation:=20
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0936r0.pdf
> I prefer P0936 over P0577 as it is completely transparent at the call sit=
e.
>
> Do any of you know if P0936 has been discussed? If so, what was the=20
> outcome?
>

Thanks for pointing out this paper, I had missed it and I agree it's an=20
improvement over P0577. P0936 was scheduled to be discussed on Friday in=20
the latest committee meeting in Jacksonville, but I can't find the minute=
=20
of the discussion. It may be that there wasn't enough time and was either=
=20
re-scheduled or deferred.

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/37f93fa9-e163-4db6-87a0-2c5e8813361d%40isocpp.or=
g.

------=_Part_12437_558140072.1527238919036
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Il giorno venerd=C3=AC 25 maggio 2018 10:49:59 UTC+2, flor=
ia...@gmail.com ha scritto:<blockquote class=3D"gmail_quote" style=3D"margi=
n: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><di=
v dir=3D"ltr">There is yet another proposal to handle lifetime propagation:=
 <a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0936r0=
..pdf" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;ht=
tp://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2F=
wg21%2Fdocs%2Fpapers%2F2018%2Fp0936r0.pdf\x26sa\x3dD\x26sntz\x3d1\x26usg\x3=
dAFQjCNEZLLKG13LZzSOWQfFwM1oInj1oHA&#39;;return true;" onclick=3D"this.href=
=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2Fjtc1=
%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2018%2Fp0936r0.pdf\x26sa\x3dD\x26sntz\x3d1=
\x26usg\x3dAFQjCNEZLLKG13LZzSOWQfFwM1oInj1oHA&#39;;return true;">http://www=
..open-std.org/jtc1/<wbr>sc22/wg21/docs/papers/2018/<wbr>p0936r0.pdf</a><br>=
I prefer P0936 over P0577 as it is completely transparent at the call site.=
<br><br>Do any of you know if P0936 has been discussed? If so, what was the=
 outcome?<br></div></blockquote><div><br></div><div>Thanks for pointing out=
 this paper, I had missed it and I agree it&#39;s an improvement over P0577=
.. P0936  was scheduled to be discussed on Friday in the latest committee me=
eting in Jacksonville, but I can&#39;t find the minute of the discussion. I=
t may be that there wasn&#39;t enough time and was either re-scheduled or d=
eferred.</div><div><br></div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/37f93fa9-e163-4db6-87a0-2c5e8813361d%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/37f93fa9-e163-4db6-87a0-2c5e8813361d=
%40isocpp.org</a>.<br />

------=_Part_12437_558140072.1527238919036--

------=_Part_12436_226214818.1527238919035--

.

------=_Part_15682_1562881146.1527286327509
Content-Type: multipart/alternative;
 boundary="----=_Part_15683_570779406.1527286327509"

------=_Part_15683_570779406.1527286327509
Content-Type: text/plain; charset="UTF-8"

On Friday, 25 May 2018 07:50:56 UTC+1, Alberto Barbati wrote:
>
>
> I agree that having a way to have a function call extend the lifetime of
> one of its arguments is better approach
>

I think you have misunderstood what I proposed. I'm wanting to give libray
authors the facility to restrict valid usage of particular methods. So that
when an expression would produce an object/handle/pointer that depends on
lifetime of another object, the compiler can give an error if the depended
upon object is known to be a destroyed before the dependee object can be
validly used.

My motivating example of code that currently compiles and runs but I'ld
like to make uncompilable
    auto it = vec<int>{5,6,7}.begin(); // In my opinion should error
    std::cout << *it << '\n';

Also
   std::weak_ptr<T> wp = ......;
   auto ptr = wp.lock().get(); // In my opinion should error

Having said that, it is interesting to know that lifetime extension
proposal as it is a related issue.


> 1) core guidelines says that it should always be possible to ignore
> attributes completely without significant changes the program behaviour. In
> this case we *do not* want the extension of the lifetime of an object to be
> "ignorable", so we definitely need a syntax that doesn't rely on attributes.
>

Not a problem as the attribute as I defined it is a restriction of valid
usage. Program behaviour would be unchanged if attributes ignored.


> 2) your proposal covers only member functions, but we have the same issue
> for regular functions. Think about function begin(x), which shares the same
> fate as x.begin().
>

This is a very good point, I need to think on how the semantics work in
this case. (+ I need to be more precise with the wording I use)

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/a0938118-f125-4dbe-97ed-955092e8ce62%40isocpp.org.

------=_Part_15683_570779406.1527286327509
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Friday, 25 May 2018 07:50:56 UTC+1, Alberto Barbati  wr=
ote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex=
;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><br><div>=
I agree that having a way to have a function call extend the lifetime of on=
e of its arguments is better approach</div></div></blockquote><div><br></di=
v><div>I think you have misunderstood what I proposed. I&#39;m wanting to g=
ive libray authors the facility to restrict valid usage of particular metho=
ds. So that when an expression would produce an object/handle/pointer that =
depends on lifetime of another object, the compiler can give an error if th=
e depended upon object is known to be a destroyed before the dependee objec=
t can be validly used. <br></div><div><br></div><div>My motivating example =
of code that currently compiles and runs but I&#39;ld like to make uncompil=
able</div><div>=C2=A0=C2=A0=C2=A0 auto it =3D vec&lt;int&gt;{5,6,7}.begin()=
; // In my opinion should error<br>=C2=A0=C2=A0=C2=A0 std::cout &lt;&lt; *i=
t &lt;&lt; &#39;\n&#39;;</div><div><br></div><div>Also</div><div>=C2=A0=C2=
=A0 std::weak_ptr&lt;T&gt; wp =3D ......;</div><div>=C2=A0=C2=A0 auto ptr =
=3D wp.lock().get(); // In my opinion should error</div><div><br></div><div=
>Having said that, it is interesting to know that lifetime extension propos=
al as it is a related issue.<br></div><div>=C2=A0</div><blockquote class=3D=
"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc s=
olid;padding-left: 1ex;"><div dir=3D"ltr"><div>1) core guidelines says that=
 it should always be possible to ignore attributes completely without signi=
ficant changes the program behaviour. In this case we *do not* want the ext=
ension of the lifetime of an object to be &quot;ignorable&quot;, so we defi=
nitely need a syntax that doesn&#39;t rely on attributes.</div></div></bloc=
kquote><div><br></div><div>Not a problem as the attribute as I defined it i=
s a restriction of valid usage. Program behaviour would be unchanged if att=
ributes ignored.<br></div><div>=C2=A0</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"ltr"><div>2) your proposal covers only member func=
tions, but we have the same issue for regular functions. Think about functi=
on begin(x), which shares the same fate as x.begin().</div></div></blockquo=
te><div><br></div><div>This is a very good point, I need to think on how th=
e semantics work in this case. (+ I need to be more precise with the wordin=
g I use)<br></div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/a0938118-f125-4dbe-97ed-955092e8ce62%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/a0938118-f125-4dbe-97ed-955092e8ce62=
%40isocpp.org</a>.<br />

------=_Part_15683_570779406.1527286327509--

------=_Part_15682_1562881146.1527286327509--

.

------=_Part_15840_35951528.1527287074219
Content-Type: multipart/alternative;
 boundary="----=_Part_15841_1216706710.1527287074219"

------=_Part_15841_1216706710.1527287074219
Content-Type: text/plain; charset="UTF-8"

On Friday, 25 May 2018 09:49:59 UTC+1, floria...@gmail.com wrote:
>
> There is yet another proposal to handle lifetime propagation:
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0936r0.pdf
> I prefer P0936 over P0577 as it is completely transparent at the call site.
>

Thank you P0936 is closest to what I'm looking for, I'll given it a read
over the weekend.

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/73c26f59-2aa0-4d89-b783-ebf73282a0bf%40isocpp.org.

------=_Part_15841_1216706710.1527287074219
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Friday, 25 May 2018 09:49:59 UTC+1, floria...@gmail.com=
  wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0=
..8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">There=
 is yet another proposal to handle lifetime propagation: <a href=3D"http://=
www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0936r0.pdf" target=3D"_bl=
ank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;http://www.google.com=
/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpaper=
s%2F2018%2Fp0936r0.pdf\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEZLLKG13LZzS=
OWQfFwM1oInj1oHA&#39;;return true;" onclick=3D"this.href=3D&#39;http://www.=
google.com/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdo=
cs%2Fpapers%2F2018%2Fp0936r0.pdf\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEZ=
LLKG13LZzSOWQfFwM1oInj1oHA&#39;;return true;">http://www.open-std.org/jtc1/=
<wbr>sc22/wg21/docs/papers/2018/<wbr>p0936r0.pdf</a><br>I prefer P0936 over=
 P0577 as it is completely transparent at the call site.<br></div></blockqu=
ote><div><br></div><div>Thank you P0936 is closest to what I&#39;m looking =
for, I&#39;ll given it a read over the weekend. <br></div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/73c26f59-2aa0-4d89-b783-ebf73282a0bf%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/73c26f59-2aa0-4d89-b783-ebf73282a0bf=
%40isocpp.org</a>.<br />

------=_Part_15841_1216706710.1527287074219--

------=_Part_15840_35951528.1527287074219--

.

------=_Part_26567_20759367.1527436447612
Content-Type: multipart/alternative;
 boundary="----=_Part_26568_2076019539.1527436447612"

------=_Part_26568_2076019539.1527436447612
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Le samedi 26 mai 2018 00:24:34 UTC+2, Gareth Lloyd a =C3=A9crit :
>
> On Friday, 25 May 2018 09:49:59 UTC+1, floria...@gmail.com wrote:
>>
>> There is yet another proposal to handle lifetime propagation:=20
>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0936r0.pdf
>> I prefer P0936 over P0577 as it is completely transparent at the call=20
>> site.
>>
>
> Thank you P0936 is closest to what I'm looking for, I'll given it a read=
=20
> over the weekend.=20
>

Actually, the proposal have not settled if this should imply compilation=20
failure and lifetime extension.
What you want is compilation failure, but lifetime extension would also=20
solve most of your problems:
auto it =3D std::vector<int>{5, 4, 3, 2, 1}.begin();
// keep temporary alive as long as `it` is alive

Even with lifetime extension, it is still possible to warn/fail to compile=
=20
if lifetime extension cannot be applied (object is returned for instance).

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/a3608611-17e4-4210-8734-9918c3210b0f%40isocpp.or=
g.

------=_Part_26568_2076019539.1527436447612
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br>Le samedi 26 mai 2018 00:24:34 UTC+2, Gareth Lloyd a =
=C3=A9crit=C2=A0:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr">On Friday, 25 May 2018 09:49:59 UTC+1, <a>floria...@gmail.com</a>  wrot=
e:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bor=
der-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">There is yet ano=
ther proposal to handle lifetime propagation: <a href=3D"http://www.open-st=
d.org/jtc1/sc22/wg21/docs/papers/2018/p0936r0.pdf" rel=3D"nofollow" target=
=3D"_blank" onmousedown=3D"this.href=3D&#39;http://www.google.com/url?q\x3d=
http%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2018%2=
Fp0936r0.pdf\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEZLLKG13LZzSOWQfFwM1oI=
nj1oHA&#39;;return true;" onclick=3D"this.href=3D&#39;http://www.google.com=
/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpaper=
s%2F2018%2Fp0936r0.pdf\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEZLLKG13LZzS=
OWQfFwM1oInj1oHA&#39;;return true;">http://www.open-std.org/jtc1/<wbr>sc22/=
wg21/docs/papers/2018/<wbr>p0936r0.pdf</a><br>I prefer P0936 over P0577 as =
it is completely transparent at the call site.<br></div></blockquote><div><=
br></div><div>Thank you P0936 is closest to what I&#39;m looking for, I&#39=
;ll given it a read over the weekend. <br></div></div></blockquote><div><br=
></div><div>Actually, the proposal have not settled if this should imply co=
mpilation failure and lifetime extension.</div><div>What you want is compil=
ation failure, but lifetime extension would also solve most of your problem=
s:</div><div><div style=3D"background-color: rgb(250, 250, 250); border-col=
or: rgb(187, 187, 187); border-style: solid; border-width: 1px; overflow-wr=
ap: break-word;" class=3D"prettyprint"><code class=3D"prettyprint"><div cla=
ss=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styled-by-prett=
ify">auto</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
it </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> std</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">::</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">vector</span><span style=3D"=
color: #080;" class=3D"styled-by-prettify">&lt;int&gt;</span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #=
066;" class=3D"styled-by-prettify">5</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> </span><span style=3D"color: #066;" class=3D"styled-by-pr=
ettify">4</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><s=
pan style=3D"color: #066;" class=3D"styled-by-prettify">3</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #066;" =
class=3D"styled-by-prettify">2</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> </span><span style=3D"color: #066;" class=3D"styled-by-prettify=
">1</span><span style=3D"color: #660;" class=3D"styled-by-prettify">}.</spa=
n><span style=3D"color: #008;" class=3D"styled-by-prettify">begin</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">();</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"c=
olor: #800;" class=3D"styled-by-prettify">// keep temporary alive as long a=
s `it` is alive</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"><br></span></div></code></div><br>Even with lifetime extension, it is =
still possible to warn/fail to compile if lifetime extension cannot be appl=
ied (object is returned for instance).</div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/a3608611-17e4-4210-8734-9918c3210b0f%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/a3608611-17e4-4210-8734-9918c3210b0f=
%40isocpp.org</a>.<br />

------=_Part_26568_2076019539.1527436447612--

------=_Part_26567_20759367.1527436447612--

.

--000000000000d2e3f8056d4dfd09
Content-Type: text/plain; charset="UTF-8"

I'm not opposed to lifetime extension, but not all bugs can be fixed via
generalized lifetime extension. Certain warnings/errors must exist since it
is imposible to fix the bug.

I'm playing devils advocate here, so lets assume we were to go all in on
lifetime extension and make it work throughout our code. In that case, in
my opinion it would require the dependent type to fundementally be changed,
if it depends on any temporaries. The dependent type is now responsible for
the lifetime of what it is bound to. That includes space requirement, copy,
move and destruction. It fully behaves like the expected type but it isn't
actually that type. This would make the following code possible:

auto f0(){
   using namespace std::string_literals;
   auto sv = std::string_view{"foo"s}; // what is sv?
   return sv; // what is returned here?}


If we return a new type we have no idea what the type is but we know it
acts like a string_view. This is fine for the client code of f0 as long as
it does not explicitly use the std::string_view type. If client code
actually needed to store that type then auto or decltype(f0()) can be used
or if its just used then then a string_view_concept could exist.

Lets get stranger, lets use existing libraries.

Third_Party_Type f1(){
   auto x = ...lifetimebound expression...;
   auto y = ...lifetimebound expression...;
   auto z = ...lifetimebound expression...;
   // What types does Third_Party_Type expect?
   return {std::move(x),std::move(y),std::move(z)};}

In f1 we make a Third_Party_Type but its constructor is going to have issue
with our new bound type. Nothing can be done here as we have a fixed ABI.
We can't fake it or trick it.

If we do allow lifetime extension in the form of f0 and library authors
write that way then clients are likely get annoyed when they hit situations
like f1 (one library gives something that acts like X but the other library
needs an actual X). Hence in my opinion both f0 and f1 should both be
disallowed and cause errors/warnings. This restricts us only to the form of
lifetime extension that I've read about, the temporaries lifetimes become
extended by effectivly having a hidden variable in the same scope. These
don't modify the bound type at all. But still we need to error/warn if we
return them or move them (as it detaches the lifetime from this scope and
all gaurentee of correctness lost).

My observation is that there are categories of bugs that we can only
warn/error about, no fix is possible.

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANgTfEhFEMZBbsKuJM89jTN%3DVkwGPoVXpH2Q_cGgBr0jfUHNVA%40mail.gmail.com.

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

<div dir=3D"ltr"><div>I&#39;m not opposed to lifetime extension, but not al=
l bugs can be fixed via generalized lifetime extension. Certain warnings/er=
rors must exist since it is imposible to fix the bug.<br></div><div><br></d=
iv><div>I&#39;m playing devils advocate here, so lets assume we were to go =
all in on lifetime extension and make it work throughout our code. In that =
case, in my opinion it would require the=20
dependent=20

type to fundementally be changed, if it depends on any temporaries. The dep=
endent type is now responsible for the lifetime of what it is bound to. Tha=
t includes space requirement, copy, move and destruction. It fully behaves =
like the expected type but it isn&#39;t actually that type. This would make=
 the following code possible:</div><div><br></div>
<pre style=3D"color:rgb(0,0,0);background:rgb(255,255,255) none repeat scro=
ll 0% 0%"><span style=3D"color:rgb(128,0,0);font-weight:bold">auto</span> f=
0<span style=3D"color:rgb(128,128,48)">(</span><span style=3D"color:rgb(128=
,128,48)">)</span>
<span style=3D"color:rgb(128,0,128)">{</span>
   <span style=3D"color:rgb(128,0,0);font-weight:bold">using</span> <span s=
tyle=3D"color:rgb(128,0,0);font-weight:bold">namespace</span> <span style=
=3D"color:rgb(102,102,22)">std</span><span style=3D"color:rgb(128,0,128)">:=
:</span>string_literals<span style=3D"color:rgb(128,0,128)">;</span>
   <span style=3D"color:rgb(128,0,0);font-weight:bold">auto</span> sv <span=
 style=3D"color:rgb(128,128,48)">=3D</span> <span style=3D"color:rgb(102,10=
2,22)">std</span><span style=3D"color:rgb(128,0,128)">::</span>string_view<=
span style=3D"color:rgb(128,0,128)">{</span><span style=3D"color:rgb(128,0,=
0)">&quot;</span><span style=3D"color:rgb(0,0,230)">foo</span><span style=
=3D"color:rgb(128,0,0)">&quot;</span>s<span style=3D"color:rgb(128,0,128)">=
}</span><span style=3D"color:rgb(128,0,128)">;</span> <span style=3D"color:=
rgb(105,105,105)">// what is sv?</span>
   <span style=3D"color:rgb(128,0,0);font-weight:bold">return</span> sv<spa=
n style=3D"color:rgb(128,0,128)">;</span> <span style=3D"color:rgb(105,105,=
105)">// what is returned here?</span>
<span style=3D"color:rgb(128,0,128)">}</span></pre>

<br><div>If we return a new type we have no idea what the type is but we kn=
ow it acts like a string_view. This is fine for the client code of f0 as lo=
ng as it does not explicitly use the std::string_view type. If client code =
actually needed to store that type then auto or decltype(f0()) can be used =
or if its just used then then a string_view_concept could exist.</div><div>=
<br></div><div>Lets get stranger, lets use existing libraries.</div>
<pre style=3D"color:rgb(0,0,0);background:rgb(255,255,255) none repeat scro=
ll 0% 0%">Third_Party_Type f1<span style=3D"color:rgb(128,128,48)">(</span>=
<span style=3D"color:rgb(128,128,48)">)</span>
<span style=3D"color:rgb(128,0,128)">{</span>
   <span style=3D"color:rgb(128,0,0);font-weight:bold">auto</span> x <span =
style=3D"color:rgb(128,128,48)">=3D</span> <span style=3D"color:rgb(128,128=
,48)">.</span><span style=3D"color:rgb(128,128,48)">.</span><span style=3D"=
color:rgb(128,128,48)">.</span>lifetimebound expression<span style=3D"color=
:rgb(128,128,48)">.</span><span style=3D"color:rgb(128,128,48)">.</span><sp=
an style=3D"color:rgb(128,128,48)">.</span><span style=3D"color:rgb(128,0,1=
28)">;</span>
   <span style=3D"color:rgb(128,0,0);font-weight:bold">auto</span> y <span =
style=3D"color:rgb(128,128,48)">=3D</span> <span style=3D"color:rgb(128,128=
,48)">.</span><span style=3D"color:rgb(128,128,48)">.</span><span style=3D"=
color:rgb(128,128,48)">.</span>lifetimebound expression<span style=3D"color=
:rgb(128,128,48)">.</span><span style=3D"color:rgb(128,128,48)">.</span><sp=
an style=3D"color:rgb(128,128,48)">.</span><span style=3D"color:rgb(128,0,1=
28)">;</span>
   <span style=3D"color:rgb(128,0,0);font-weight:bold">auto</span> z <span =
style=3D"color:rgb(128,128,48)">=3D</span> <span style=3D"color:rgb(128,128=
,48)">.</span><span style=3D"color:rgb(128,128,48)">.</span><span style=3D"=
color:rgb(128,128,48)">.</span>lifetimebound expression<span style=3D"color=
:rgb(128,128,48)">.</span><span style=3D"color:rgb(128,128,48)">.</span><sp=
an style=3D"color:rgb(128,128,48)">.</span><span style=3D"color:rgb(128,0,1=
28)">;</span>
   <span style=3D"color:rgb(105,105,105)">// What types does Third_Party_Ty=
pe expect?</span>
   <span style=3D"color:rgb(128,0,0);font-weight:bold">return</span> <span =
style=3D"color:rgb(128,0,128)">{</span><span style=3D"color:rgb(102,102,22)=
">std</span><span style=3D"color:rgb(128,0,128)">::</span><span style=3D"co=
lor:rgb(96,48,0)">move</span><span style=3D"color:rgb(128,128,48)">(</span>=
x<span style=3D"color:rgb(128,128,48)">)</span><span style=3D"color:rgb(128=
,128,48)">,</span><span style=3D"color:rgb(102,102,22)">std</span><span sty=
le=3D"color:rgb(128,0,128)">::</span><span style=3D"color:rgb(96,48,0)">mov=
e</span><span style=3D"color:rgb(128,128,48)">(</span>y<span style=3D"color=
:rgb(128,128,48)">)</span><span style=3D"color:rgb(128,128,48)">,</span><sp=
an style=3D"color:rgb(102,102,22)">std</span><span style=3D"color:rgb(128,0=
,128)">::</span><span style=3D"color:rgb(96,48,0)">move</span><span style=
=3D"color:rgb(128,128,48)">(</span>z<span style=3D"color:rgb(128,128,48)">)=
</span><span style=3D"color:rgb(128,0,128)">}</span><span style=3D"color:rg=
b(128,0,128)">;</span>
<span style=3D"color:rgb(128,0,128)">}</span></pre>

<div>In f1 we make a Third_Party_Type but its constructor is going to have =
issue with our new bound type. Nothing can be done here as we have a fixed =
ABI. We can&#39;t fake it or trick it.</div><div><br></div><div>If we do al=
low lifetime extension in the form of f0 and library authors write that way=
 then clients are likely get annoyed when they hit situations like f1 (one =
library gives something that acts like X but the other library needs an act=
ual X). Hence in my opinion both f0 and f1 should both be disallowed and ca=
use errors/warnings. This restricts us only to the form of lifetime extensi=
on that I&#39;ve read about, the temporaries lifetimes become extended by e=
ffectivly having a hidden variable in the same scope. These don&#39;t modif=
y the bound type at all. But still we need to error/warn if we return them =
or move them (as it detaches the lifetime from this scope and all gaurentee=
 of correctness lost). <br></div><div><br></div>My observation is that ther=
e are categories of bugs that we can only warn/error about, no fix is possi=
ble.<br></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CANgTfEhFEMZBbsKuJM89jTN%3DVkwGPoVXpH=
2Q_cGgBr0jfUHNVA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANgTfEhFEMZBbs=
KuJM89jTN%3DVkwGPoVXpH2Q_cGgBr0jfUHNVA%40mail.gmail.com</a>.<br />

--000000000000d2e3f8056d4dfd09--

.

------=_Part_34818_1757692730.1527557539195
Content-Type: multipart/alternative;
 boundary="----=_Part_34819_83906696.1527557539195"

------=_Part_34819_83906696.1527557539195
Content-Type: text/plain; charset="UTF-8"



> Even with lifetime extension, it is still possible to warn/fail to compile
> if lifetime extension cannot be applied (object is returned for instance).
>

I should re-read more carefully before writting long replies.

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/1ff61a56-191f-49c2-849d-b3bb47b52930%40isocpp.org.

------=_Part_34819_83906696.1527557539195
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><div>Even with lifetime extension, it is still possible to warn/fa=
il to compile if lifetime extension cannot be applied (object is returned f=
or instance).</div></div></blockquote><div><br></div><div>I should re-read =
more carefully before writting long replies.=C2=A0 <br></div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/1ff61a56-191f-49c2-849d-b3bb47b52930%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/1ff61a56-191f-49c2-849d-b3bb47b52930=
%40isocpp.org</a>.<br />

------=_Part_34819_83906696.1527557539195--

------=_Part_34818_1757692730.1527557539195--

.

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

So after a long walk today I finally have been able to point at what makes
me uneasy about the lifetime extension approach. In short, if we depend
upon more than one lifetimebound object which are temporaries, then as it
currently stands they are unsequenced. Consider the following example:
=E2=80=8B

#include <string>#include <iostream>
struct Foo
{
    static int counter;

    std::string s;

    Foo(std::string const & _s) : s{_s + std::to_string(counter++)}
    {
        std::cout << "ctr " << s << '\n';
    }
    ~Foo(){std::cout << "dtr " << s << '\n';}
};
int Foo::counter =3D 0;
auto f0(Foo const & foo1 /*lifetimebound*/, Foo const & foo2 /*lifetimeboun=
d*/)
{
    return [&](){std::cout << foo1.s << '-' << foo2.s << '\n';};
}
int main()
{
    using namespace std::string_literals;
    auto x =3D f0("a"s, "b"s);
    x();
}

With or without lifetime extension, the temporaries that foo1 and foo2
are bound to have undefined sequence of construction. This is a
problem for temporaries as it currently is, but if we enhance lifetime
extension and encourage the use of temporaries then this will
possibly be a common pitfall.

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CANgTfEgedZZj1%3D3ydxBcZf9AMNNZvXG4Ndk6zTFxBNUU5=
X8e1w%40mail.gmail.com.

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

<div dir=3D"ltr">So after a long walk today I finally have been able to poi=
nt at what makes me uneasy about the lifetime extension approach. In short,=
 if we depend upon more than one lifetimebound=20

object which are temporaries, then as it currently stands they are unsequen=
ced. Consider the following example:<br><div>=E2=80=8B
<pre style=3D"margin:0px;line-height:125%"><span style=3D"color:rgb(85,119,=
153)">#include &lt;string&gt;</span>
<span style=3D"color:rgb(85,119,153)">#include &lt;iostream&gt;</span>

<span style=3D"color:rgb(0,136,0);font-weight:bold">struct</span> Foo
{
    <span style=3D"color:rgb(0,136,0);font-weight:bold">static</span> <span=
 style=3D"color:rgb(51,51,153);font-weight:bold">int</span> counter;
   =20
    std<span style=3D"color:rgb(51,51,51)">::</span>string s;
   =20
    Foo(std<span style=3D"color:rgb(51,51,51)">::</span>string <span style=
=3D"color:rgb(0,136,0);font-weight:bold">const</span> <span style=3D"color:=
rgb(51,51,51)">&amp;</span> _s) <span style=3D"color:rgb(51,51,51)">:</span=
> s{_s <span style=3D"color:rgb(51,51,51)">+</span> std<span style=3D"color=
:rgb(51,51,51)">::</span>to_string(counter<span style=3D"color:rgb(51,51,51=
)">++</span>)}=20
    {=20
        std<span style=3D"color:rgb(51,51,51)">::</span>cout <span style=3D=
"color:rgb(51,51,51)">&lt;&lt;</span> <span style=3D"background-color:rgb(2=
55,240,240)">&quot;ctr &quot;</span> <span style=3D"color:rgb(51,51,51)">&l=
t;&lt;</span> s <span style=3D"color:rgb(51,51,51)">&lt;&lt;</span> <span s=
tyle=3D"color:rgb(0,68,221)">&#39;\n&#39;</span>;
    }
    <span style=3D"color:rgb(51,51,51)">~</span>Foo(){std<span style=3D"col=
or:rgb(51,51,51)">::</span>cout <span style=3D"color:rgb(51,51,51)">&lt;&lt=
;</span> <span style=3D"background-color:rgb(255,240,240)">&quot;dtr &quot;=
</span> <span style=3D"color:rgb(51,51,51)">&lt;&lt;</span> s <span style=
=3D"color:rgb(51,51,51)">&lt;&lt;</span> <span style=3D"color:rgb(0,68,221)=
">&#39;\n&#39;</span>;}
};

<span style=3D"color:rgb(51,51,153);font-weight:bold">int</span> Foo<span s=
tyle=3D"color:rgb(51,51,51)">::</span>counter <span style=3D"color:rgb(51,5=
1,51)">=3D</span> <span style=3D"color:rgb(0,0,221);font-weight:bold">0</sp=
an>;

<span style=3D"color:rgb(0,136,0);font-weight:bold">auto</span> <span style=
=3D"color:rgb(0,102,187);font-weight:bold">f0</span>(Foo <span style=3D"col=
or:rgb(0,136,0);font-weight:bold">const</span> <span style=3D"color:rgb(51,=
51,51)">&amp;</span> foo1 <span style=3D"color:rgb(136,136,136)">/*lifetime=
bound*/</span>, Foo <span style=3D"color:rgb(0,136,0);font-weight:bold">con=
st</span> <span style=3D"color:rgb(51,51,51)">&amp;</span> foo2 <span style=
=3D"color:rgb(136,136,136)">/*lifetimebound*/</span>)
{
    <span style=3D"color:rgb(0,136,0);font-weight:bold">return</span> [<spa=
n style=3D"color:rgb(51,51,51)">&amp;</span>](){std<span style=3D"color:rgb=
(51,51,51)">::</span>cout <span style=3D"color:rgb(51,51,51)">&lt;&lt;</spa=
n> foo1.s <span style=3D"color:rgb(51,51,51)">&lt;&lt;</span> <span style=
=3D"color:rgb(0,68,221)">&#39;-&#39;</span> <span style=3D"color:rgb(51,51,=
51)">&lt;&lt;</span> foo2.s <span style=3D"color:rgb(51,51,51)">&lt;&lt;</s=
pan> <span style=3D"color:rgb(0,68,221)">&#39;\n&#39;</span>;};
}

<span style=3D"color:rgb(51,51,153);font-weight:bold">int</span> <span styl=
e=3D"color:rgb(0,102,187);font-weight:bold">main</span>()
{
    <span style=3D"color:rgb(0,136,0);font-weight:bold">using</span> <span =
style=3D"color:rgb(0,136,0);font-weight:bold">namespace</span> std<span sty=
le=3D"color:rgb(51,51,51)">::</span>string_literals;
    <span style=3D"color:rgb(0,136,0);font-weight:bold">auto</span> x <span=
 style=3D"color:rgb(51,51,51)">=3D</span> f0(<span style=3D"background-colo=
r:rgb(255,240,240)">&quot;a&quot;</span>s, <span style=3D"background-color:=
rgb(255,240,240)">&quot;b&quot;</span>s);
    x();
}<br><br>
</pre><pre style=3D"margin:0px;line-height:125%"><font face=3D"arial,helvet=
ica,sans-serif">With or without lifetime extension, the temporaries that fo=
o1 and foo2 are bound to have undefined sequence of construction. This is a=
 <br>problem for temporaries as it currently is, but if we enhance lifetime=
 extension and encourage the use of temporaries then this will <br>possibly=
 be a common pitfall. </font></pre></div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CANgTfEgedZZj1%3D3ydxBcZf9AMNNZvXG4Nd=
k6zTFxBNUU5X8e1w%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANgTfEgedZZj1%=
3D3ydxBcZf9AMNNZvXG4Ndk6zTFxBNUU5X8e1w%40mail.gmail.com</a>.<br />

--000000000000489c8a056dda257a--

.

------=_Part_38184_1693041824.1528173058786
Content-Type: multipart/alternative;
 boundary="----=_Part_38185_1761327257.1528173058787"

------=_Part_38185_1761327257.1528173058787
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Monday, June 4, 2018 at 8:29:41 PM UTC-4, Gareth Lloyd wrote:
>
> So after a long walk today I finally have been able to point at what make=
s=20
> me uneasy about the lifetime extension approach. In short, if we depend=
=20
> upon more than one lifetimebound object which are temporaries, then as it=
=20
> currently stands they are unsequenced. Consider the following example:
> =E2=80=8B=20
>
> #include <string>#include <iostream>
> struct Foo
> {
>     static int counter;
>    =20
>     std::string s;
>    =20
>     Foo(std::string const & _s) : s{_s + std::to_string(counter++)}=20
>     {=20
>         std::cout << "ctr " << s << '\n';
>     }
>     ~Foo(){std::cout << "dtr " << s << '\n';}
> };
> int Foo::counter =3D 0;
> auto f0(Foo const & foo1 /*lifetimebound*/, Foo const & foo2 /*lifetimebo=
und*/)
> {
>     return [&](){std::cout << foo1.s << '-' << foo2.s << '\n';};
> }
> int main()
> {
>     using namespace std::string_literals;
>     auto x =3D f0("a"s, "b"s);
>     x();
> }
>
> With or without lifetime extension, the temporaries that foo1 and foo2 ar=
e bound to have undefined sequence of construction. This is a=20
> problem for temporaries as it currently is, but if we enhance lifetime ex=
tension and encourage the use of temporaries then this will=20
> possibly be a common pitfall.
>
>
I don't see how this would be any more of a problem in the future than it=
=20
is now. If `f0` didn't store those temporaries in the return value, they=20
would still "have undefined sequence of construction" relative to one=20
another. Yet people write code that constructs multiple temporaries in=20
function parameters *all the time*. So I fail to see how the possibility of=
=20
such faults will be significantly raised by lifetime extension.

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/8365b751-0310-4199-8be7-d6222b078aff%40isocpp.or=
g.

------=_Part_38185_1761327257.1528173058787
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Monday, June 4, 2018 at 8:29:41 PM UTC-4, Gareth Lloyd =
wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">So afte=
r a long walk today I finally have been able to point at what makes me unea=
sy about the lifetime extension approach. In short, if we depend upon more =
than one lifetimebound=20

object which are temporaries, then as it currently stands they are unsequen=
ced. Consider the following example:<br><div>=E2=80=8B
<pre style=3D"margin:0px;line-height:125%"><span style=3D"color:rgb(85,119,=
153)">#include &lt;string&gt;</span>
<span style=3D"color:rgb(85,119,153)">#include &lt;iostream&gt;</span>

<span style=3D"color:rgb(0,136,0);font-weight:bold">struct</span> Foo
{
    <span style=3D"color:rgb(0,136,0);font-weight:bold">static</span> <span=
 style=3D"color:rgb(51,51,153);font-weight:bold">int</span> counter;
   =20
    std<span style=3D"color:rgb(51,51,51)">::</span>string s;
   =20
    Foo(std<span style=3D"color:rgb(51,51,51)">::</span>string <span style=
=3D"color:rgb(0,136,0);font-weight:bold">const</span> <span style=3D"color:=
rgb(51,51,51)">&amp;</span> _s) <span style=3D"color:rgb(51,51,51)">:</span=
> s{_s <span style=3D"color:rgb(51,51,51)">+</span> std<span style=3D"color=
:rgb(51,51,51)">::</span>to_string(counter<span style=3D"color:rgb(51,51,51=
)">++</span>)}=20
    {=20
        std<span style=3D"color:rgb(51,51,51)">::</span>cout <span style=3D=
"color:rgb(51,51,51)">&lt;&lt;</span> <span style=3D"background-color:rgb(2=
55,240,240)">&quot;ctr &quot;</span> <span style=3D"color:rgb(51,51,51)">&l=
t;&lt;</span> s <span style=3D"color:rgb(51,51,51)">&lt;&lt;</span> <span s=
tyle=3D"color:rgb(0,68,221)">&#39;\n&#39;</span>;
    }
    <span style=3D"color:rgb(51,51,51)">~</span>Foo(){std<span style=3D"col=
or:rgb(51,51,51)">::</span>cout <span style=3D"color:rgb(51,51,51)">&lt;&lt=
;</span> <span style=3D"background-color:rgb(255,240,240)">&quot;dtr &quot;=
</span> <span style=3D"color:rgb(51,51,51)">&lt;&lt;</span> s <span style=
=3D"color:rgb(51,51,51)">&lt;&lt;</span> <span style=3D"color:rgb(0,68,221)=
">&#39;\n&#39;</span>;}
};

<span style=3D"color:rgb(51,51,153);font-weight:bold">int</span> Foo<span s=
tyle=3D"color:rgb(51,51,51)">::</span>counter <span style=3D"color:rgb(51,5=
1,51)">=3D</span> <span style=3D"color:rgb(0,0,221);font-weight:bold">0</sp=
an>;

<span style=3D"color:rgb(0,136,0);font-weight:bold">auto</span> <span style=
=3D"color:rgb(0,102,187);font-weight:bold">f0</span>(Foo <span style=3D"col=
or:rgb(0,136,0);font-weight:bold">const</span> <span style=3D"color:rgb(51,=
51,51)">&amp;</span> foo1 <span style=3D"color:rgb(136,136,136)">/*lifetime=
bound*/</span>, Foo <span style=3D"color:rgb(0,136,0);font-weight:bold">con=
st</span> <span style=3D"color:rgb(51,51,51)">&amp;</span> foo2 <span style=
=3D"color:rgb(136,136,136)">/*lifetimebound*/</span>)
{
    <span style=3D"color:rgb(0,136,0);font-weight:bold">return</span> [<spa=
n style=3D"color:rgb(51,51,51)">&amp;</span>](){std<span style=3D"color:rgb=
(51,51,51)">::</span>cout <span style=3D"color:rgb(51,51,51)">&lt;&lt;</spa=
n> foo1.s <span style=3D"color:rgb(51,51,51)">&lt;&lt;</span> <span style=
=3D"color:rgb(0,68,221)">&#39;-&#39;</span> <span style=3D"color:rgb(51,51,=
51)">&lt;&lt;</span> foo2.s <span style=3D"color:rgb(51,51,51)">&lt;&lt;</s=
pan> <span style=3D"color:rgb(0,68,221)">&#39;\n&#39;</span>;};
}

<span style=3D"color:rgb(51,51,153);font-weight:bold">int</span> <span styl=
e=3D"color:rgb(0,102,187);font-weight:bold">main</span>()
{
    <span style=3D"color:rgb(0,136,0);font-weight:bold">using</span> <span =
style=3D"color:rgb(0,136,0);font-weight:bold">namespace</span> std<span sty=
le=3D"color:rgb(51,51,51)">::</span>string_literals;
    <span style=3D"color:rgb(0,136,0);font-weight:bold">auto</span> x <span=
 style=3D"color:rgb(51,51,51)">=3D</span> f0(<span style=3D"background-colo=
r:rgb(255,240,240)">&quot;a&quot;</span>s, <span style=3D"background-color:=
rgb(255,240,240)">&quot;b&quot;</span>s);
    x();
}<br><br>
</pre><pre style=3D"margin:0px;line-height:125%"><font face=3D"arial,helvet=
ica,sans-serif">With or without lifetime extension, the temporaries that fo=
o1 and foo2 are bound to have undefined sequence of construction. This is a=
 <br>problem for temporaries as it currently is, but if we enhance lifetime=
 extension and encourage the use of temporaries then this will <br>possibly=
 be a common pitfall.</font></pre></div></div></blockquote><div><br></div><=
div>I don&#39;t see how this would be any more of a problem in the future t=
han it is now. If `f0` didn&#39;t store those temporaries in the return val=
ue, they would still &quot;have undefined sequence of construction&quot; re=
lative to one another. Yet people write code that constructs multiple tempo=
raries in function parameters <i>all the time</i>. So I fail to see how the=
 possibility of such faults will be significantly raised by lifetime extens=
ion.</div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/8365b751-0310-4199-8be7-d6222b078aff%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/8365b751-0310-4199-8be7-d6222b078aff=
%40isocpp.org</a>.<br />

------=_Part_38185_1761327257.1528173058787--

------=_Part_38184_1693041824.1528173058786--

.