(http://open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0007r0.html)

I like the general idea here, but looking at the Further Discussion
section, I see it appears that the lifetime issues have not been solved.
That being the case, I don't think that the relative advantages and
disadvantages are entirely accurate. In fact, I consider the proposed
implementation to be irresponsibly dangerous, as it accepts an rvalue
but allows the same to be destroyed before it can be used. The assertion
that it can be backported is at any rate dubious.

While it's true that we want lifetime extension anyway, the reality is
that std::as_const *also* doesn't work without core language changes,
i.e. as a library-only solution it is incomplete. Moreover, I don't see
that it cannot be made to work at all for an rvalue of a type that is
not {copy,move}able without introducing mandatory copy elision. (The
suggested alternative implementation cannot be used for such case, and
the original as mentioned yields a destroyed object.)

Conversely, 'const <expr>' (or '(const)<expr>', '<expr> const', etc.) is
completely safe and should be much easier to implement, as it has no
effect on lifetime and doesn't require the compiler to do any optimizing
/ lifetime gymnastics, but merely modify the state of the AST. (The
"looks like a C-style cast" drawback also applies only to one specific
form, and likely not the one that would be preferred.)

Considering that my primary use case for such a feature is the RHS of a
range-based for, which may well be a rvalue, I feel that the rationale
for a library-only solution is problematic and the claim that a proper
language solution has only "marginal gain" is incorrect. The benefit of
a langauge-based solution is that it *would actually work*, which IMHO
makes it far superior.

--
Matthew

--

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

.

On 2 October 2015 at 17:38, Matthew Woehlke <mwoehlke.floss@gmail.com> wrote:
> While it's true that we want lifetime extension anyway, the reality is
> that std::as_const *also* doesn't work without core language changes,
> i.e. as a library-only solution it is incomplete. Moreover, I don't see
> that it cannot be made to work at all for an rvalue of a type that is
> not {copy,move}able without introducing mandatory copy elision. (The

Ah, yes, the rvalue overload is returning by value, which doesn't work for
forwarding cases. Then again, for forwarding cases, one can forward<const T>()
so perhaps that wasn't important.

--

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

.

--Apple-Mail=_D9C1848B-833F-449D-8E99-E4A4ECEC163F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8


> On 2015=E2=80=9310=E2=80=9302, at 10:45 PM, Ville Voutilainen <ville.vout=
ilainen@gmail.com> wrote:
>=20
> On 2 October 2015 at 17:38, Matthew Woehlke <mwoehlke.floss@gmail.com> wr=
ote:
>> While it's true that we want lifetime extension anyway, the reality is
>> that std::as_const *also* doesn't work without core language changes,
>> i.e. as a library-only solution it is incomplete. Moreover, I don't see
>> that it cannot be made to work at all for an rvalue of a type that is
>> not {copy,move}able without introducing mandatory copy elision. (The
>=20
> Ah, yes, the rvalue overload is returning by value, which doesn't work fo=
r
> forwarding cases. Then again, for forwarding cases, one can forward<const=
 T>()
> so perhaps that wasn't important.

If T is a reference type, then const will be ignored in forward<const T>.

It=E2=80=99s another use case for generalized lifetime extension (P0066) bu=
t I=E2=80=99m not sure whether that proposal is getting closer or further :=
P

A core language feature, const(expr) or const{expr} parsed as if const was =
a simple-type-specifier, would produce temporary expressions=E2=80=A6

--=20

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

--Apple-Mail=_D9C1848B-833F-449D-8E99-E4A4ECEC163F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9310=
=E2=80=9302, at 10:45 PM, Ville Voutilainen &lt;<a href=3D"mailto:ville.vou=
tilainen@gmail.com" class=3D"">ville.voutilainen@gmail.com</a>&gt; wrote:</=
div><br class=3D"Apple-interchange-newline"><div class=3D"">On 2 October 20=
15 at 17:38, Matthew Woehlke &lt;<a href=3D"mailto:mwoehlke.floss@gmail.com=
" class=3D"">mwoehlke.floss@gmail.com</a>&gt; wrote:<br class=3D""><blockqu=
ote type=3D"cite" class=3D"">While it's true that we want lifetime extensio=
n anyway, the reality is<br class=3D"">that std::as_const *also* doesn't wo=
rk without core language changes,<br class=3D"">i.e. as a library-only solu=
tion it is incomplete. Moreover, I don't see<br class=3D"">that it cannot b=
e made to work at all for an rvalue of a type that is<br class=3D"">not {co=
py,move}able without introducing mandatory copy elision. (The<br class=3D""=
></blockquote><br class=3D"">Ah, yes, the rvalue overload is returning by v=
alue, which doesn't work for<br class=3D"">forwarding cases. Then again, fo=
r forwarding cases, one can forward&lt;const T&gt;()<br class=3D"">so perha=
ps that wasn't important.<br class=3D""></div></blockquote><div><br class=
=3D""></div><div>If&nbsp;<span style=3D"font-family: Courier;" class=3D"">T=
</span>&nbsp;is a reference type, then&nbsp;<span style=3D"font-family: Cou=
rier;" class=3D"">const</span>&nbsp;will be ignored in <font face=3D"Courie=
r" class=3D"">forward&lt;const T&gt;</font>.</div></div><br class=3D""><div=
 class=3D"">It=E2=80=99s another use case for generalized lifetime extensio=
n (P0066) but I=E2=80=99m not sure whether that proposal is getting closer =
or further :P</div><div class=3D""><br class=3D""></div><div class=3D"">A c=
ore language feature, <font face=3D"Courier" class=3D"">const(expr)</font> =
or <font face=3D"Courier" class=3D"">const{expr}</font>&nbsp;parsed as if&n=
bsp;<span style=3D"font-family: Courier;" class=3D"">const</span>&nbsp;was =
a simple-type-specifier, would produce temporary expressions=E2=80=A6</div>=
<div class=3D""><br class=3D""></div></body></html>

<p></p>

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

--Apple-Mail=_D9C1848B-833F-449D-8E99-E4A4ECEC163F--

.