------=_Part_1885_1446217995.1459919990989
Content-Type: multipart/alternative;
 boundary="----=_Part_1886_53620473.1459919990989"

------=_Part_1886_53620473.1459919990989
Content-Type: text/plain; charset=UTF-8

On Tuesday, April 5, 2016 at 4:58:18 PM UTC-7, isocp...@denisbider.com
wrote:
>
>
> This would now be exception-safe:
>
> - without requiring pilfering;
> - and without a potentially, but almost never, valueless variant.
>

Only for types that actually offered the relocation operation. You can't
assume that all user-defined types will support this. Thus variant must
continue to have some kind of valueless state to satisfy the other
constraints.

--
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/4187538d-68fa-4582-ba26-f406479abe67%40isocpp.org.

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

<div dir=3D"ltr">On Tuesday, April 5, 2016 at 4:58:18 PM UTC-7, isocp...@de=
nisbider.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D=
"ltr"><div><br></div><div>This would now be exception-safe:</div><div><br><=
/div><div>- without requiring pilfering;</div><div>- and without a=C2=A0pot=
entially, but almost never, valueless variant.</div></div></blockquote><div=
><br></div><div>Only for types that actually offered the relocation operati=
on. You can&#39;t assume that all user-defined types will support this. Thu=
s variant must continue to have some kind of valueless state to satisfy the=
 other constraints.</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/4187538d-68fa-4582-ba26-f406479abe67%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/4187538d-68fa-4582-ba26-f406479abe67=
%40isocpp.org</a>.<br />

------=_Part_1886_53620473.1459919990989--
------=_Part_1885_1446217995.1459919990989--

.

------=_Part_2019_535804517.1459957682184
Content-Type: multipart/alternative;
 boundary="----=_Part_2020_1600044663.1459957682184"

------=_Part_2020_1600044663.1459957682184
Content-Type: text/plain; charset=UTF-8

Types with throwing move constructors are prime candidates to have a
relocator, because it solves a problem specific to them. A relocator can be
implemented trivially, without changing the design of a non-nullable type
like the particular std::list implementation. It would not require changing
the fundamental design of the type, which implementing a noexcept move
constructor would require.

For user types, relocators would be implicitly defined by the compiler,
under much the same terms as a move constructor.

I'm not seeing a plausible usage case where you would want a type to have a
throwing move constructor, and *not* implement a relocator. It seems
plausible this combination could be unsupported.


On Tuesday, April 5, 2016 at 11:19:51 PM UTC-6, Sean Middleditch wrote:

> On Tuesday, April 5, 2016 at 4:58:18 PM UTC-7, isocp...@denisbider.com
> wrote:
>>
>>
>> This would now be exception-safe:
>>
>> - without requiring pilfering;
>> - and without a potentially, but almost never, valueless variant.
>>
>
> Only for types that actually offered the relocation operation. You can't
> assume that all user-defined types will support this. Thus variant must
> continue to have some kind of valueless state to satisfy the other
> constraints.
>

--
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/eafd831f-85d2-430c-9969-7d084e6d28d2%40isocpp.org.

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

<div dir=3D"ltr"><div>Types with throwing move constructors are prime candi=
dates to have a relocator, because it solves a problem specific to them. A =
relocator can be implemented trivially, without changing the design of a no=
n-nullable type like the particular std::list implementation. It would not =
require changing the fundamental design of the type, which implementing a n=
oexcept move constructor would require.</div><div><br></div><div>For user t=
ypes, relocators would be implicitly defined by the compiler, under much th=
e same terms as a move constructor.</div><div><br></div><div>I&#39;m not se=
eing a plausible usage case where you would want a type to have a throwing =
move constructor, and <strong>not</strong> implement a relocator. It seems =
plausible this combination could be unsupported.</div><div><br><br>On Tuesd=
ay, April 5, 2016 at 11:19:51 PM UTC-6, Sean Middleditch wrote:</div><block=
quote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-lef=
t: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px; bord=
er-left-style: solid;"><div dir=3D"ltr">On Tuesday, April 5, 2016 at 4:58:1=
8 PM UTC-7, <a>isocp...@denisbider.com</a> wrote:<blockquote class=3D"gmail=
_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-=
color: rgb(204, 204, 204); border-left-width: 1px; border-left-style: solid=
;"><div dir=3D"ltr"><div><br></div><div>This would now be exception-safe:</=
div><div><br></div><div>- without requiring pilfering;</div><div>- and with=
out a=C2=A0potentially, but almost never, valueless variant.</div></div></b=
lockquote><div><br></div><div>Only for types that actually offered the relo=
cation operation. You can&#39;t assume that all user-defined types will sup=
port this. Thus variant must continue to have some kind of valueless state =
to satisfy the other constraints.</div></div></blockquote></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/eafd831f-85d2-430c-9969-7d084e6d28d2%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/eafd831f-85d2-430c-9969-7d084e6d28d2=
%40isocpp.org</a>.<br />

------=_Part_2020_1600044663.1459957682184--
------=_Part_2019_535804517.1459957682184--

.

On Wed, Apr 6, 2016 at 8:48 AM,  <eloandrheo@gmail.com> wrote:
> Types with throwing move constructors are prime candidates to have a
> relocator, because it solves a problem specific to them. A relocator can be
> implemented trivially, without changing the design of a non-nullable type
> like the particular std::list implementation. It would not require changing
> the fundamental design of the type, which implementing a noexcept move
> constructor would require.
>
> For user types, relocators would be implicitly defined by the compiler,
> under much the same terms as a move constructor.
>
> I'm not seeing a plausible usage case where you would want a type to have a
> throwing move constructor, and not implement a relocator. It seems plausible
> this combination could be unsupported.

Much existing code simply wouldn't support relocation properly until
someone went in and wrote the relocator functions. You can't generate
correct relocations for all types, e.g. those with non-trivial move
constructors that do who-knows-what. Those existing types would become
incompatible with variants were variant to rely on relocation. That
level of requirements has so far been a show stopper for suggestions
to "fix" variant.

The committee can mandate that standard library types all have
relocators added where necessary but it can do no such thing for user
types. However, the committee _does_ want to allow variant to be used
with those same problematic user types.


I personally find this relocation proposal currently incomplete and in
need of a lot more iteration. With your proposal, it's way too easy to
accidentally leave some object in an undefined state where the
compiler has no idea and is stuck calling the destructor anyway. All
it takes is passing an object via pointer to some function and *bam*
insta-pain, as the caller has no way to know what the function will do
and the function has no way to know what the caller wanted to allow,
other than comments and documentation (no compiler support for error
checking). Standardizable relocation support in C++ is likely to
require more work on value categories and probably some kind of new
reference or wrapper type (one that cannot be very easily and
accidentally bound to sub-objects or glvalues).

--
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/CALQmNFggBQSADjEqS7pEzcdPSStGJfXkJdX0d2CwW_TmwqA%3DyQ%40mail.gmail.com.

.

On 2016-04-06 12:07, Sean Middleditch wrote:
> I personally find this relocation proposal currently incomplete and in
> need of a lot more iteration. With your proposal, it's way too easy to
> accidentally leave some object in an undefined state where the
> compiler has no idea and is stuck calling the destructor anyway. All
> it takes is passing an object via pointer to some function and *bam*
> insta-pain, as the caller has no way to know what the function will do
> and the function has no way to know what the caller wanted to allow,
> other than comments and documentation (no compiler support for error
> checking).

Right now, if I pass a pointer to an object to a function, that function
can `delete` the pointer. How does relocation make this any worse? In
both cases, the pointer passed in is no longer valid.

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/ne3cod%24a8n%241%40ger.gmane.org.

.

------=_Part_2136_539717698.1459961711375
Content-Type: multipart/alternative;
 boundary="----=_Part_2137_128809297.1459961711375"

------=_Part_2137_128809297.1459961711375
Content-Type: text/plain; charset=UTF-8



> The committee can mandate that standard library types all have
> relocators added where necessary but it can do no such thing for
> user types. However, the committee _does_ want to allow variant
> to be used with those same problematic user types.

With respect to variant, it is already a major advantage of relocation that
it can support:

- exception-safe use of variant with non-nullable standard library types -
without requiring an existing std::list implementation to be thrown away so
it can be nothrow_move_constructible;

- exception-safe use of variant with future non-nullable types.

Existing problematic non-library types can of course still be supported, if
we're willing to lose the strong exception safety guarantee in that case.
I'm not sure there is a silver bullet that can avoid that.


> With your proposal, it's way too easy to accidentally leave
> some object in an undefined state

I find this logic highly questionable. By this line of reasoning, we should
remove placement new, C-style casts, and manual memory management, so that
C++ might become a managed language.

C++ involves low-level tools that have to be used correctly. Relocation is
one. It is safer than current practice, which is to memcpy objects, which
invokes undefined behavior and is horrible for static analysis. Relocation
allows objects to be moved, while allowing static analysis tools to reason
about the program.


The general advantage of relocation is that it supports future use of
non-nullable types in C++ at all. If relocation is not implemented,
non-nullable types will remain fundamentally incompatible with C++ move
semantics, and will have to go the way of the Dodo.

Forcing all objects to have null states creates another instance of what
has been called the Billion-Dollar Mistake:

http://www.infoq.com/presentations/Null-References-The-Billion-Dollar-Mistake-Tony-Hoare

Except for some reason, we are now doing this with object states.


On Wednesday, April 6, 2016 at 10:07:11 AM UTC-6, Sean Middleditch wrote:
On Wed, Apr 6, 2016 at 8:48 AM,  <eloan...@gmail.com> wrote:
> Types with throwing move constructors are prime candidates to have a
> relocator, because it solves a problem specific to them. A relocator can
be
> implemented trivially, without changing the design of a non-nullable type
> like the particular std::list implementation. It would not require
changing
> the fundamental design of the type, which implementing a noexcept move
> constructor would require.
>
> For user types, relocators would be implicitly defined by the compiler,
> under much the same terms as a move constructor.
>
> I'm not seeing a plausible usage case where you would want a type to have
a
> throwing move constructor, and not implement a relocator. It seems
plausible
> this combination could be unsupported.

Much existing code simply wouldn't support relocation properly until
someone went in and wrote the relocator functions. You can't generate
correct relocations for all types, e.g. those with non-trivial move
constructors that do who-knows-what. Those existing types would become
incompatible with variants were variant to rely on relocation. That
level of requirements has so far been a show stopper for suggestions
to "fix" variant.

The committee can mandate that standard library types all have
relocators added where necessary but it can do no such thing for user
types. However, the committee _does_ want to allow variant to be used
with those same problematic user types.


I personally find this relocation proposal currently incomplete and in
need of a lot more iteration. With your proposal, it's way too easy to
accidentally leave some object in an undefined state where the
compiler has no idea and is stuck calling the destructor anyway. All
it takes is passing an object via pointer to some function and *bam*
insta-pain, as the caller has no way to know what the function will do
and the function has no way to know what the caller wanted to allow,
other than comments and documentation (no compiler support for error
checking). Standardizable relocation support in C++ is likely to
require more work on value categories and probably some kind of new
reference or wrapper type (one that cannot be very easily and
accidentally bound to sub-objects or glvalues).

--
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/105d82bc-e1cf-4795-894c-112cd591c3af%40isocpp.org.

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

<div dir=3D"ltr"><p>&gt; The committee can mandate that standard library ty=
pes all have<br>&gt; relocators added where necessary but it can do no such=
 thing for<br>&gt; user types. However, the committee _does_ want to allow =
variant<br>&gt; to be used with those same problematic user types. </p><div=
><br></div><div>With respect to variant, it is already a major advantage of=
 relocation that it can support:</div><div><br></div><div>- exception-safe =
use of variant with non-nullable standard library types - without requiring=
 an existing std::list implementation to be thrown away so it can be nothro=
w_move_constructible;</div><p>- exception-safe use of variant with future n=
on-nullable types.</p><div><br></div><div>Existing problematic non-library =
types can of course still be supported, if we&#39;re willing to lose the st=
rong exception safety guarantee in that case. I&#39;m not sure there is a s=
ilver bullet that can avoid that.</div><div><br></div><div><br></div><div>&=
gt; With your proposal, it&#39;s way too easy to accidentally leave<br>&gt;=
 some object in an undefined state</div><div><br></div><div>I find this log=
ic highly questionable. By this line of reasoning, we should remove placeme=
nt new, C-style casts, and manual memory management, so that C++ might beco=
me a managed language.</div><div><br></div><div>C++ involves low-level tool=
s that have to be used correctly. Relocation is one.=C2=A0It is safer than =
current practice, which is to memcpy objects, which invokes undefined behav=
ior and is horrible for static analysis. Relocation allows objects to be mo=
ved, while allowing static analysis tools to reason about the program.</div=
><div><br></div><div><br>The general=C2=A0advantage of relocation is that i=
t supports future use of non-nullable types in C++ at all. If relocation is=
 not implemented, non-nullable types will remain fundamentally incompatible=
 with C++ move semantics, and will have to go the way of the Dodo.</div><di=
v><br></div><div>Forcing all objects to have null states creates another in=
stance of what has been called the Billion-Dollar Mistake:</div><div><br></=
div><div><a href=3D"http://www.infoq.com/presentations/Null-References-The-=
Billion-Dollar-Mistake-Tony-Hoare">http://www.infoq.com/presentations/Null-=
References-The-Billion-Dollar-Mistake-Tony-Hoare</a></div><div><br></div><d=
iv>Except for some reason, we are now doing this with object states.</div><=
div><br></div><div><br>On Wednesday, April 6, 2016 at 10:07:11 AM UTC-6, Se=
an Middleditch wrote:<br>On Wed, Apr 6, 2016 at 8:48 AM,=C2=A0 &lt;<a href=
=3D"mailto:eloan...@gmail.com">eloan...@gmail.com</a>&gt; wrote: <br>&gt; T=
ypes with throwing move constructors are prime candidates to have a <br>&gt=
; relocator, because it solves a problem specific to them. A relocator can =
be <br>&gt; implemented trivially, without changing the design of a non-nul=
lable type <br>&gt; like the particular std::list implementation. It would =
not require changing <br>&gt; the fundamental design of the type, which imp=
lementing a noexcept move <br>&gt; constructor would require. <br>&gt; <br>=
&gt; For user types, relocators would be implicitly defined by the compiler=
, <br>&gt; under much the same terms as a move constructor. <br>&gt; <br>&g=
t; I&#39;m not seeing a plausible usage case where you would want a type to=
 have a <br>&gt; throwing move constructor, and not implement a relocator. =
It seems plausible <br>&gt; this combination could be unsupported. </div><p=
>Much existing code simply wouldn&#39;t support relocation properly until <=
br>someone went in and wrote the relocator functions. You can&#39;t generat=
e <br>correct relocations for all types, e.g. those with non-trivial move <=
br>constructors that do who-knows-what. Those existing types would become <=
br>incompatible with variants were variant to rely on relocation. That <br>=
level of requirements has so far been a show stopper for suggestions <br>to=
 &quot;fix&quot; variant. </p><p>The committee can mandate that standard li=
brary types all have <br>relocators added where necessary but it can do no =
such thing for user <br>types. However, the committee _does_ want to allow =
variant to be used <br>with those same problematic user types. </p><p><br>I=
 personally find this relocation proposal currently incomplete and in <br>n=
eed of a lot more iteration. With your proposal, it&#39;s way too easy to <=
br>accidentally leave some object in an undefined state where the <br>compi=
ler has no idea and is stuck calling the destructor anyway. All <br>it take=
s is passing an object via pointer to some function and *bam* <br>insta-pai=
n, as the caller has no way to know what the function will do <br>and the f=
unction has no way to know what the caller wanted to allow, <br>other than =
comments and documentation (no compiler support for error <br>checking). St=
andardizable relocation support in C++ is likely to <br>require more work o=
n value categories and probably some kind of new <br>reference or wrapper t=
ype (one that cannot be very easily and <br>accidentally bound to sub-objec=
ts or glvalues). <br></p></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/105d82bc-e1cf-4795-894c-112cd591c3af%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/105d82bc-e1cf-4795-894c-112cd591c3af=
%40isocpp.org</a>.<br />

------=_Part_2137_128809297.1459961711375--
------=_Part_2136_539717698.1459961711375--

.

------=_Part_407_121844994.1459965956051
Content-Type: multipart/alternative;
 boundary="----=_Part_408_329220491.1459965956052"

------=_Part_408_329220491.1459965956052
Content-Type: text/plain; charset=UTF-8



On Wednesday, April 6, 2016 at 12:55:11 PM UTC-4, isocp...@denisbider.com
wrote:
>
> > The committee can mandate that standard library types all have
> > relocators added where necessary but it can do no such thing for
> > user types. However, the committee _does_ want to allow variant
> > to be used with those same problematic user types.
>
> With respect to variant, it is already a major advantage of relocation
> that it can support:
>
> - exception-safe use of variant with non-nullable standard library types -
> without requiring an existing std::list implementation to be thrown away so
> it can be nothrow_move_constructible;
>
> - exception-safe use of variant with future non-nullable types.
>
> Existing problematic non-library types can of course still be supported,
> if we're willing to lose the strong exception safety guarantee in that
> case. I'm not sure there is a silver bullet that can avoid that.
>

In which case, variant will still need to have a valueless state in order
to support such types. Which means that, at the end of the day,
"relocation" doesn't solve the problem.

Indeed, P0308 doesn't seem to recognize that its own solution doesn't solve
the problem either. Because the implicit conversions on parameters given to
`emplace`-style assignment operations can throw as well. So even with types
that are noexcept moveable, you can still wind up with a valueless variant.

> With your proposal, it's way too easy to accidentally leave
> > some object in an undefined state
>
> I find this logic highly questionable. By this line of reasoning, we
> should remove placement new, C-style casts, and manual memory management,
> so that C++ might become a managed language.
>

No, that line of reasoning doesn't follow at all.

There is absolutely no reason why we can't come up with a way to abscond
with an object's resources and destroy it in the same action. Indeed, this
forum is practically littered with ideas just like your "relocation" stuff.
Such discussions call the idea "destructive move" or something similar. But
overall, it's the same basic idea: abscond with resources and destroy the
object. A great deal of discussion has taken place about ensuring that
movement and destruction happen as a single action, to ensure that you
don't leave objects broken.

Hence the term "destructive move": the object is moved from and *destroyed*.
I personally prefer that idea to what is basically just another form of
"move, but I really *really* mean it this time." After all, the reason why
move is problematic is that you're allowed to talk to the object later, so
you have to deal with what the object's state is after the move. If you
destroy the object as it is being moved from, then you don't have this
problem.

My overall point is that unsafety is not a requirement of resolving this
problem. So there's no reason to use an unsafe idea when there are safer
alternatives.

--
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/c4034cda-9ea4-4855-b718-6ed7b1f1d7c2%40isocpp.org.

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

<div dir=3D"ltr"><br><br>On Wednesday, April 6, 2016 at 12:55:11 PM UTC-4, =
isocp...@denisbider.com wrote:<blockquote class=3D"gmail_quote" style=3D"ma=
rgin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">=
<div dir=3D"ltr"><p>&gt; The committee can mandate that standard library ty=
pes all have<br>&gt; relocators added where necessary but it can do no such=
 thing for<br>&gt; user types. However, the committee _does_ want to allow =
variant<br>&gt; to be used with those same problematic user types. </p><div=
><br></div><div>With respect to variant, it is already a major advantage of=
 relocation that it can support:</div><div><br></div><div>- exception-safe =
use of variant with non-nullable standard library types - without requiring=
 an existing std::list implementation to be thrown away so it can be nothro=
w_move_constructible;</div><p>- exception-safe use of variant with future n=
on-nullable types.</p><div><br></div><div>Existing problematic non-library =
types can of course still be supported, if we&#39;re willing to lose the st=
rong exception safety guarantee in that case. I&#39;m not sure there is a s=
ilver bullet that can avoid that.</div></div></blockquote><div><br>In which=
 case, variant will still need to have a valueless state in order to suppor=
t such types. Which means that, at the end of the day, &quot;relocation&quo=
t; doesn&#39;t solve the problem.<br><br>Indeed, P0308 doesn&#39;t seem to =
recognize that its own solution doesn&#39;t solve the problem either. Becau=
se the implicit conversions on parameters given to `emplace`-style assignme=
nt operations can throw as well. So even with types that are noexcept movea=
ble, you can still wind up with a valueless variant.<br><br></div><blockquo=
te 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></div><div>&gt; W=
ith your proposal, it&#39;s way too easy to accidentally leave<br>&gt; some=
 object in an undefined state</div><div><br></div><div>I find this logic hi=
ghly questionable. By this line of reasoning, we should remove placement ne=
w, C-style casts, and manual memory management, so that C++ might become a =
managed language.</div></div></blockquote><div><br>No, that line of reasoni=
ng doesn&#39;t follow at all.<br><br>There is absolutely no reason why we c=
an&#39;t come up with a way to abscond with an object&#39;s resources and d=
estroy it in the same action. Indeed, this forum is practically littered wi=
th ideas just like your &quot;relocation&quot; stuff. Such discussions call=
 the idea &quot;destructive move&quot; or something similar. But overall, i=
t&#39;s the same basic idea: abscond with resources and destroy the object.=
 A great deal of discussion has taken place about ensuring that movement an=
d destruction happen as a single action, to ensure that you don&#39;t leave=
 objects broken.<br><br>Hence the term &quot;destructive move&quot;: the ob=
ject is moved from and <i>destroyed</i>. I personally prefer that idea to w=
hat is basically just another form of &quot;move, but I really <i>really</i=
> mean it this time.&quot; After all, the reason why move is problematic is=
 that you&#39;re allowed to talk to the object later, so you have to deal w=
ith what the object&#39;s state is after the move. If you destroy the objec=
t as it is being moved from, then you don&#39;t have this problem.<br><br>M=
y overall point is that unsafety is not a requirement of resolving this pro=
blem. So there&#39;s no reason to use an unsafe idea when there are safer a=
lternatives.<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/c4034cda-9ea4-4855-b718-6ed7b1f1d7c2%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/c4034cda-9ea4-4855-b718-6ed7b1f1d7c2=
%40isocpp.org</a>.<br />

------=_Part_408_329220491.1459965956052--
------=_Part_407_121844994.1459965956051--

.

------=_Part_465_558292139.1459966919792
Content-Type: multipart/alternative;
 boundary="----=_Part_466_1751615627.1459966919793"

------=_Part_466_1751615627.1459966919793
Content-Type: text/plain; charset=UTF-8


>
> Hence the term "destructive move": the object is moved from and
> *destroyed*. I personally prefer that idea to what is basically just
> another form of "move, but I really *really* mean it this time."
>

What do you consider as the difference between the two? I've always thought
of destructive move as basically just that - move but seriously it's dead
now e.g.:

T x;
T y = std::destructive_move(x); // or whatever the syntax ends up being
x.bar(); // error, x is actually dead. not mostly dead. dead.

 Regardless, is there anything new on the destructive move front? I don't
see any new papers on the topic over the last few mailings...

--
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/57841c61-2780-4ee7-9421-516119e81536%40isocpp.org.

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

<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr"><div>Hence the term &quot;destructive move&quot;: the object is moved f=
rom and <i>destroyed</i>. I personally prefer that idea to what is basicall=
y just another form of &quot;move, but I really <i>really</i> mean it this =
time.&quot;=C2=A0<br></div></div></blockquote><div><br></div><div>What do y=
ou consider as the difference between the two? I&#39;ve always thought of d=
estructive move as basically just that - move but seriously it&#39;s dead n=
ow e.g.:</div><div><br></div><div><div class=3D"prettyprint" style=3D"borde=
r: 1px solid rgb(187, 187, 187); word-wrap: break-word; background-color: r=
gb(250, 250, 250);"><code class=3D"prettyprint"><div class=3D"subprettyprin=
t"><font color=3D"#660066"><span style=3D"color: #000;" class=3D"styled-by-=
prettify">T x</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>T =
y </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"> std</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">::</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">destructive_move</span><span=
 style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify">x</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">);</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> </span><span style=3D"color: #800;" class=3D"st=
yled-by-prettify">// or whatever the syntax ends up being</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br>x</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">.</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify">bar</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">();</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> </span><span style=3D"color: #800;" class=3D"styled-by-=
prettify">// error, x is actually dead. not mostly dead. dead. </span></fon=
t></div></code></div><div><br></div>=C2=A0Regardless, is there anything new=
 on the destructive move front? I don&#39;t see any new papers on the topic=
 over the last few mailings...=C2=A0</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/57841c61-2780-4ee7-9421-516119e81536%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/57841c61-2780-4ee7-9421-516119e81536=
%40isocpp.org</a>.<br />

------=_Part_466_1751615627.1459966919793--
------=_Part_465_558292139.1459966919792--

.

------=_Part_2129_1046542627.1459968855839
Content-Type: multipart/alternative;
 boundary="----=_Part_2130_74661097.1459968855840"

------=_Part_2130_74661097.1459968855840
Content-Type: text/plain; charset=UTF-8

Nicol,

relocation *is* a destructive move. The relocator is a constructor for the
new object, and destructor for the old object, rolled in one.

I think this is spelled out quite clearly in the proposal. The old object
does not continue to live after.

Relocation and destructive move *are the same thing*.


> In which case, variant will still need to have a valueless state in order
to support such types.

This cost can be borne by a specialization of the variant available to
those who want a variant that is compatible with problematic types.

Again, this is under the presumption that you want a variant that's
compatible with problematic types where a variant can only be implemented
unsafely. I find this a questionable presumption.


> Because the implicit conversions on parameters given to `emplace`-style
assignment operations can throw as well.

P0308 does not solve this, but relocation does! Emplace construction can be
done in a temporary, which is then relocated into the variant.


On Wednesday, April 6, 2016 at 12:05:56 PM UTC-6, Nicol Bolas wrote:

>
>
> On Wednesday, April 6, 2016 at 12:55:11 PM UTC-4, isocp...@denisbider.com
> wrote:
>>
>> > The committee can mandate that standard library types all have
>> > relocators added where necessary but it can do no such thing for
>> > user types. However, the committee _does_ want to allow variant
>> > to be used with those same problematic user types.
>>
>> With respect to variant, it is already a major advantage of relocation
>> that it can support:
>>
>> - exception-safe use of variant with non-nullable standard library types
>> - without requiring an existing std::list implementation to be thrown away
>> so it can be nothrow_move_constructible;
>>
>> - exception-safe use of variant with future non-nullable types.
>>
>> Existing problematic non-library types can of course still be supported,
>> if we're willing to lose the strong exception safety guarantee in that
>> case. I'm not sure there is a silver bullet that can avoid that.
>>
>
> In which case, variant will still need to have a valueless state in order
> to support such types. Which means that, at the end of the day,
> "relocation" doesn't solve the problem.
>
> Indeed, P0308 doesn't seem to recognize that its own solution doesn't
> solve the problem either. Because the implicit conversions on parameters
> given to `emplace`-style assignment operations can throw as well. So even
> with types that are noexcept moveable, you can still wind up with a
> valueless variant.
>
> > With your proposal, it's way too easy to accidentally leave
>> > some object in an undefined state
>>
>> I find this logic highly questionable. By this line of reasoning, we
>> should remove placement new, C-style casts, and manual memory management,
>> so that C++ might become a managed language.
>>
>
> No, that line of reasoning doesn't follow at all.
>
> There is absolutely no reason why we can't come up with a way to abscond
> with an object's resources and destroy it in the same action. Indeed, this
> forum is practically littered with ideas just like your "relocation" stuff.
> Such discussions call the idea "destructive move" or something similar. But
> overall, it's the same basic idea: abscond with resources and destroy the
> object. A great deal of discussion has taken place about ensuring that
> movement and destruction happen as a single action, to ensure that you
> don't leave objects broken.
>
> Hence the term "destructive move": the object is moved from and
> *destroyed*. I personally prefer that idea to what is basically just
> another form of "move, but I really *really* mean it this time." After
> all, the reason why move is problematic is that you're allowed to talk to
> the object later, so you have to deal with what the object's state is after
> the move. If you destroy the object as it is being moved from, then you
> don't have this problem.
>
> My overall point is that unsafety is not a requirement of resolving this
> problem. So there's no reason to use an unsafe idea when there are safer
> alternatives.
>

--
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/20f375ac-22f1-4af0-8321-91a9e7d135c2%40isocpp.org.

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

<div dir=3D"ltr"><div>Nicol,</div><div><br></div><div>relocation <em>is</em=
> a destructive move. The relocator is a constructor for the new object, an=
d destructor for the old object, rolled in one.</div><div><br></div><div>I =
think this is spelled out quite clearly in the proposal. The old object doe=
s not continue to live after.</div><div><br></div><div>Relocation and destr=
uctive move <em>are the same thing</em>.</div><div><br></div><div><br></div=
><div>&gt; In which case, variant will still need to have a valueless state=
 in order to support such types.</div><div><br></div><div>This cost can be =
borne by a=C2=A0specialization of the variant available to those who want a=
 variant that is compatible with problematic types.</div><div><br></div><di=
v>Again, this is under the presumption that you want a variant that&#39;s c=
ompatible with problematic types where a variant can only be implemented un=
safely.=C2=A0I find this a questionable presumption.</div><div><br></div><d=
iv><br></div><div>&gt; Because the implicit conversions on parameters given=
 to `emplace`-style assignment operations can throw as well.</div><div><br>=
</div><div>P0308 does not solve this, but relocation does! Emplace construc=
tion can be done in a temporary, which is then relocated into the variant.<=
/div><div><br></div><div><br>On Wednesday, April 6, 2016 at 12:05:56 PM UTC=
-6, Nicol Bolas wrote:</div><blockquote class=3D"gmail_quote" style=3D"marg=
in: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, =
204); border-left-width: 1px; border-left-style: solid;"><div dir=3D"ltr"><=
br><br>On Wednesday, April 6, 2016 at 12:55:11 PM UTC-4, <a>isocp...@denisb=
ider.com</a> wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0=
px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); bor=
der-left-width: 1px; border-left-style: solid;"><div dir=3D"ltr"><p>&gt; Th=
e committee can mandate that standard library types all have<br>&gt; reloca=
tors added where necessary but it can do no such thing for<br>&gt; user typ=
es. However, the committee _does_ want to allow variant<br>&gt; to be used =
with those same problematic user types. </p><div><br></div><div>With respec=
t to variant, it is already a major advantage of relocation that it can sup=
port:</div><div><br></div><div>- exception-safe use of variant with non-nul=
lable standard library types - without requiring an existing std::list impl=
ementation to be thrown away so it can be nothrow_move_constructible;</div>=
<p>- exception-safe use of variant with future non-nullable types.</p><div>=
<br></div><div>Existing problematic non-library types can of course still b=
e supported, if we&#39;re willing to lose the strong exception safety guara=
ntee in that case. I&#39;m not sure there is a silver bullet that can avoid=
 that.</div></div></blockquote><div><br>In which case, variant will still n=
eed to have a valueless state in order to support such types. Which means t=
hat, at the end of the day, &quot;relocation&quot; doesn&#39;t solve the pr=
oblem.<br><br>Indeed, P0308 doesn&#39;t seem to recognize that its own solu=
tion doesn&#39;t solve the problem either. Because the implicit conversions=
 on parameters given to `emplace`-style assignment operations can throw as =
well. So even with types that are noexcept moveable, you can still wind up =
with a valueless variant.<br><br></div><blockquote class=3D"gmail_quote" st=
yle=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb=
(204, 204, 204); border-left-width: 1px; border-left-style: solid;"><div di=
r=3D"ltr"><div></div><div>&gt; With your proposal, it&#39;s way too easy to=
 accidentally leave<br>&gt; some object in an undefined state</div><div><br=
></div><div>I find this logic highly questionable. By this line of reasonin=
g, we should remove placement new, C-style casts, and manual memory managem=
ent, so that C++ might become a managed language.</div></div></blockquote><=
div><br>No, that line of reasoning doesn&#39;t follow at all.<br><br>There =
is absolutely no reason why we can&#39;t come up with a way to abscond with=
 an object&#39;s resources and destroy it in the same action. Indeed, this =
forum is practically littered with ideas just like your &quot;relocation&qu=
ot; stuff. Such discussions call the idea &quot;destructive move&quot; or s=
omething similar. But overall, it&#39;s the same basic idea: abscond with r=
esources and destroy the object. A great deal of discussion has taken place=
 about ensuring that movement and destruction happen as a single action, to=
 ensure that you don&#39;t leave objects broken.<br><br>Hence the term &quo=
t;destructive move&quot;: the object is moved from and <i>destroyed</i>. I =
personally prefer that idea to what is basically just another form of &quot=
;move, but I really <i>really</i> mean it this time.&quot; After all, the r=
eason why move is problematic is that you&#39;re allowed to talk to the obj=
ect later, so you have to deal with what the object&#39;s state is after th=
e move. If you destroy the object as it is being moved from, then you don&#=
39;t have this problem.<br><br>My overall point is that unsafety is not a r=
equirement of resolving this problem. So there&#39;s no reason to use an un=
safe idea when there are safer alternatives.<br></div></div></blockquote></=
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/20f375ac-22f1-4af0-8321-91a9e7d135c2%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/20f375ac-22f1-4af0-8321-91a9e7d135c2=
%40isocpp.org</a>.<br />

------=_Part_2130_74661097.1459968855840--
------=_Part_2129_1046542627.1459968855839--

.

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

On Apr 6, 2016 9:55 AM, <isocppgroup@denisbider.com> wrote:
>
> > The committee can mandate that standard library types all have
> > relocators added where necessary but it can do no such thing for
> > user types. However, the committee _does_ want to allow variant
> > to be used with those same problematic user types.
>
>
> With respect to variant, it is already a major advantage of relocation
that it can support:
>
> - exception-safe use of variant with non-nullable standard library types
- without requiring an existing std::list implementation to be thrown away
so it can be nothrow_move_constructible;
>
> - exception-safe use of variant with future non-nullable types.

But not "exception safe" for other types, meaning that it still requires
the work around with the valueless state. So we go from a "mostly never
empty" container to a "slightly more mostly never empty" container. :)

>
>
> Existing problematic non-library types can of course still be supported,
if we're willing to lose the strong exception safety guarantee in that
case. I'm not sure there is a silver bullet that can avoid that.
>
>
> > With your proposal, it's way too easy to accidentally leave
> > some object in an undefined state
>
> I find this logic highly questionable. By this line of reasoning, we
should remove placement new, C-style casts, and manual memory management,
so that C++ might become a managed language.

Not at all, and that's quite the logical jump. For one, your feature
doesn't actually exist yet, while those others do; adding unsafe features
and keeping old unsafe features (that we actually _do_ kinda-sorta
deprecate, e.g. the modern advice to never ever use new/delete or C-style
casts) for back-compat are two very different things. :)

For two, there are degrees of ease-of- misuse and not just a binary
equation of assembly vs C# :)  Rust for instance is a case of going too far
with protecting users from mistakes and going straight into forcing users
to jump through hoops to convince the compiler of the validity of perfectly
valid code. It errs completely on the side of safety. Nobody is (seriously)
advocating that for C++. Neither should we be advocating to adding more
C-level-dangerous constructs to C++ without darn good reason. Half-fixing
variant and not actually fixing many _other_ major problems that
destructive move could solve (e.g., accidentally using a moved-from
parameter instead of the moved-to member in a class constructor).

For three, your feature proposal opens whole new classes of mistakes than
what we have today. The only mechanism even close to being as dangerous is
delete/free and modern C++ all but deprecates those features in user code,
even in high-performance situations like AAA games. A "good" destructive
move should _reduce_ errors in existing code -- like accidentally using
moved-from values -- rather than adding new ones. Performance alone isn't
good enough. Remember, rvalue references _real_ goal was to allow us to
replace things like the easy-to-misuse auto_ptr with the much superior
unique_ptr. The potential performance improvements of move semantics were
icing on the cake.

Now let's be clear: the intent of relocation is good. We need someone
working on this, IMO. I'm more than happy to see you work on it; you seem
like a pretty bright person and are obviously passionate about the issue. I
just strongly think that the proposal you currently have just isn't "there"
yet and needs more design iteration. :)

>

--
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/CALQmNFja3Kt1XRR8S7Qr3rOktChVzuDGO7ZtSaQpsWaohU6wAA%40mail.gmail.com.

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

<div dir=3D"ltr"><p dir=3D"ltr"><br>
On Apr 6, 2016 9:55 AM, &lt;<a href=3D"mailto:isocppgroup@denisbider.com" t=
arget=3D"_blank">isocppgroup@denisbider.com</a>&gt; wrote:<br>
&gt;<br>
&gt; &gt; The committee can mandate that standard library types all have<br=
>
&gt; &gt; relocators added where necessary but it can do no such thing for<=
br>
&gt; &gt; user types. However, the committee _does_ want to allow variant<b=
r>
&gt; &gt; to be used with those same problematic user types.<br>
&gt;<br>
&gt;<br>
&gt; With respect to variant, it is already a major advantage of relocation=
 that it can support:<br>
&gt;<br>
&gt; - exception-safe use of variant with non-nullable standard library typ=
es - without requiring an existing std::list implementation to be thrown aw=
ay so it can be nothrow_move_constructible;<br>
&gt;<br>
&gt; - exception-safe use of variant with future non-nullable types.</p><p>=
But not &quot;exception safe&quot; for other types, meaning that it still r=
equires the work around with the valueless state. So we go from a &quot;mos=
tly never empty&quot; container to a &quot;slightly more mostly never empty=
&quot; container. :)</p><p dir=3D"ltr">
&gt;<br>
&gt;<br>
&gt; Existing problematic non-library types can of course still be supporte=
d, if we&#39;re willing to lose the strong exception safety guarantee in th=
at case. I&#39;m not sure there is a silver bullet that can avoid that.<br>
&gt;<br>
&gt;<br>
&gt; &gt; With your proposal, it&#39;s way too easy to accidentally leave<b=
r>
&gt; &gt; some object in an undefined state<br>
&gt;<br>
&gt; I find this logic highly questionable. By this line of reasoning, we s=
hould remove placement new, C-style casts, and manual memory management, so=
 that C++ might become a managed language.</p>
<p dir=3D"ltr">Not at all, and that&#39;s quite the logical jump. For one, =
your feature doesn&#39;t actually exist yet, while those others do; adding =
unsafe features and keeping old unsafe features (that we actually _do_ kind=
a-sorta deprecate, e.g. the modern advice to never ever use new/delete or C=
-style casts) for back-compat are two very different things. :)</p>
<p dir=3D"ltr">For two, there are degrees of ease-of- misuse and not just a=
 binary equation of assembly vs C# :) =C2=A0Rust for instance is a case of =
going too far with protecting users from mistakes and going straight into f=
orcing users to jump through hoops to convince the compiler of the validity=
 of perfectly valid code. It errs completely on the side of safety. Nobody =
is (seriously) advocating that for C++. Neither should we be advocating to =
adding more C-level-dangerous constructs to C++ without darn good reason. H=
alf-fixing variant and not actually fixing many _other_ major problems that=
 destructive move could solve (e.g., accidentally using a moved-from parame=
ter instead of the moved-to member in a class constructor).</p>
<p dir=3D"ltr">For three, your feature proposal opens whole new classes of =
mistakes than what we have today. The only mechanism even close to being as=
 dangerous is delete/free and modern C++ all but deprecates those features =
in user code, even in high-performance situations like AAA games. A &quot;g=
ood&quot; destructive move should _reduce_ errors in existing code -- like =
accidentally using moved-from values -- rather than adding new ones. Perfor=
mance alone isn&#39;t good enough. Remember, rvalue references _real_ goal =
was to allow us to replace things like the easy-to-misuse auto_ptr with the=
 much superior unique_ptr. The potential performance improvements of move s=
emantics were icing on the cake.</p>
<p dir=3D"ltr">Now let&#39;s be clear: the intent of relocation is good. We=
 need someone working on this, IMO. I&#39;m more than happy to see you work=
 on it; you seem like a pretty bright person and are obviously passionate a=
bout the issue. I just strongly think that the proposal you currently have =
just isn&#39;t &quot;there&quot; yet and needs more design iteration. :)</p=
>
<p dir=3D"ltr">&gt;<br>
</p>
</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/CALQmNFja3Kt1XRR8S7Qr3rOktChVzuDGO7Zt=
SaQpsWaohU6wAA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALQmNFja3Kt1XRR8=
S7Qr3rOktChVzuDGO7ZtSaQpsWaohU6wAA%40mail.gmail.com</a>.<br />

--001a1141855a213891052fddbe90--

.

------=_Part_130_2079848649.1460090294215
Content-Type: multipart/alternative;
 boundary="----=_Part_131_229753461.1460090294215"

------=_Part_131_229753461.1460090294215
Content-Type: text/plain; charset=UTF-8

Hey Sean,

if you would like to see move destruction / relocation proposed in a safer
form, do you have any ideas about what that safer form would look like?

You refer to that modern C++ discourages direct use of new and delete.
Well, yes, of course. But libraries still need to use new and delete, as
well as placement new, to implement containers. How would you propose
implementing the standard library without these features?

It is not the intention of this Relocator proposal to be used directly by
end users. The intention is that it would be used in STL implementations,
to solve problems that a lack of destructive move makes difficult.

Language users should not have to worry about invoking or implementing
relocators, in much the same way they shouldn't have to worry about move
constructors. Language users should use standard library types, and it's up
to the library types to implement relocators and move constructors.

If you have any ideas of how the proposed feature can be made safer, I
would love to hear about it.

However, this is not to be mistaken for a feature that end users should
directly use.


On Wednesday, April 6, 2016 at 10:45:09 PM UTC-6, Sean Middleditch wrote:

>
> On Apr 6, 2016 9:55 AM, <isocp...@denisbider.com <javascript:>> wrote:
> >
> > > The committee can mandate that standard library types all have
> > > relocators added where necessary but it can do no such thing for
> > > user types. However, the committee _does_ want to allow variant
> > > to be used with those same problematic user types.
> >
> >
> > With respect to variant, it is already a major advantage of relocation
> that it can support:
> >
> > - exception-safe use of variant with non-nullable standard library types
> - without requiring an existing std::list implementation to be thrown away
> so it can be nothrow_move_constructible;
> >
> > - exception-safe use of variant with future non-nullable types.
>
> But not "exception safe" for other types, meaning that it still requires
> the work around with the valueless state. So we go from a "mostly never
> empty" container to a "slightly more mostly never empty" container. :)
>
> >
> >
> > Existing problematic non-library types can of course still be supported,
> if we're willing to lose the strong exception safety guarantee in that
> case. I'm not sure there is a silver bullet that can avoid that.
> >
> >
> > > With your proposal, it's way too easy to accidentally leave
> > > some object in an undefined state
> >
> > I find this logic highly questionable. By this line of reasoning, we
> should remove placement new, C-style casts, and manual memory management,
> so that C++ might become a managed language.
>
> Not at all, and that's quite the logical jump. For one, your feature
> doesn't actually exist yet, while those others do; adding unsafe features
> and keeping old unsafe features (that we actually _do_ kinda-sorta
> deprecate, e.g. the modern advice to never ever use new/delete or C-style
> casts) for back-compat are two very different things. :)
>
> For two, there are degrees of ease-of- misuse and not just a binary
> equation of assembly vs C# :)  Rust for instance is a case of going too far
> with protecting users from mistakes and going straight into forcing users
> to jump through hoops to convince the compiler of the validity of perfectly
> valid code. It errs completely on the side of safety. Nobody is (seriously)
> advocating that for C++. Neither should we be advocating to adding more
> C-level-dangerous constructs to C++ without darn good reason. Half-fixing
> variant and not actually fixing many _other_ major problems that
> destructive move could solve (e.g., accidentally using a moved-from
> parameter instead of the moved-to member in a class constructor).
>
> For three, your feature proposal opens whole new classes of mistakes than
> what we have today. The only mechanism even close to being as dangerous is
> delete/free and modern C++ all but deprecates those features in user code,
> even in high-performance situations like AAA games. A "good" destructive
> move should _reduce_ errors in existing code -- like accidentally using
> moved-from values -- rather than adding new ones. Performance alone isn't
> good enough. Remember, rvalue references _real_ goal was to allow us to
> replace things like the easy-to-misuse auto_ptr with the much superior
> unique_ptr. The potential performance improvements of move semantics were
> icing on the cake.
>
> Now let's be clear: the intent of relocation is good. We need someone
> working on this, IMO. I'm more than happy to see you work on it; you seem
> like a pretty bright person and are obviously passionate about the issue. I
> just strongly think that the proposal you currently have just isn't "there"
> yet and needs more design iteration. :)
>
> >
>

--
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/4f31b957-05be-47cf-a1ca-03f33a9900c0%40isocpp.org.

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

<div dir=3D"ltr"><div>Hey Sean,</div><div><br></div><div>if you=C2=A0would =
like to see=C2=A0move destruction / relocation proposed in a safer form, do=
 you have any ideas about what that safer form would look like?</div><div><=
br></div><div>You refer to that modern C++ discourages direct use of new an=
d delete. Well, yes, of course. But libraries still need to use new and del=
ete,=C2=A0as well as=C2=A0placement new,=C2=A0to implement containers. How =
would you propose implementing the standard library without these features?=
</div><div><br></div><div>It is not the intention of this Relocator proposa=
l to be used directly by end users. The intention is that it would be used =
in STL implementations, to solve problems that a lack of destructive move m=
akes difficult.</div><div><br></div><div>Language users should not have to =
worry about invoking or implementing relocators, in much the same way they =
shouldn&#39;t have to worry about move constructors. Language users should =
use standard library types, and it&#39;s up to the library types to impleme=
nt relocators and move constructors.</div><div><br></div><div>If you have a=
ny ideas of how=C2=A0the proposed feature=C2=A0can be made safer, I would l=
ove to hear about it.</div><div><br></div><div>However, this is not to be m=
istaken for a feature that end users should directly use.</div><div><br><br=
>On Wednesday, April 6, 2016 at 10:45:09 PM UTC-6, Sean Middleditch wrote:<=
/div><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; =
padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width=
: 1px; border-left-style: solid;"><div dir=3D"ltr"><p dir=3D"ltr"><br>
On Apr 6, 2016 9:55 AM, &lt;<a onmousedown=3D"this.href=3D&#39;javascript:&=
#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true=
;" href=3D"javascript:" target=3D"_blank" rel=3D"nofollow" gdf-obfuscated-m=
ailto=3D"VosGVw0oAgAJ">isocp...@denisbider.com</a>&gt; wrote:<br>
&gt;<br>
&gt; &gt; The committee can mandate that standard library types all have<br=
>
&gt; &gt; relocators added where necessary but it can do no such thing for<=
br>
&gt; &gt; user types. However, the committee _does_ want to allow variant<b=
r>
&gt; &gt; to be used with those same problematic user types.<br>
&gt;<br>
&gt;<br>
&gt; With respect to variant, it is already a major advantage of relocation=
 that it can support:<br>
&gt;<br>
&gt; - exception-safe use of variant with non-nullable standard library typ=
es - without requiring an existing std::list implementation to be thrown aw=
ay so it can be nothrow_move_constructible;<br>
&gt;<br>
&gt; - exception-safe use of variant with future non-nullable types.</p><p>=
But not &quot;exception safe&quot; for other types, meaning that it still r=
equires the work around with the valueless state. So we go from a &quot;mos=
tly never empty&quot; container to a &quot;slightly more mostly never empty=
&quot; container. :)</p><p dir=3D"ltr">
&gt;<br>
&gt;<br>
&gt; Existing problematic non-library types can of course still be supporte=
d, if we&#39;re willing to lose the strong exception safety guarantee in th=
at case. I&#39;m not sure there is a silver bullet that can avoid that.<br>
&gt;<br>
&gt;<br>
&gt; &gt; With your proposal, it&#39;s way too easy to accidentally leave<b=
r>
&gt; &gt; some object in an undefined state<br>
&gt;<br>
&gt; I find this logic highly questionable. By this line of reasoning, we s=
hould remove placement new, C-style casts, and manual memory management, so=
 that C++ might become a managed language.</p>
<p dir=3D"ltr">Not at all, and that&#39;s quite the logical jump. For one, =
your feature doesn&#39;t actually exist yet, while those others do; adding =
unsafe features and keeping old unsafe features (that we actually _do_ kind=
a-sorta deprecate, e.g. the modern advice to never ever use new/delete or C=
-style casts) for back-compat are two very different things. :)</p>
<p dir=3D"ltr">For two, there are degrees of ease-of- misuse and not just a=
 binary equation of assembly vs C# :) =C2=A0Rust for instance is a case of =
going too far with protecting users from mistakes and going straight into f=
orcing users to jump through hoops to convince the compiler of the validity=
 of perfectly valid code. It errs completely on the side of safety. Nobody =
is (seriously) advocating that for C++. Neither should we be advocating to =
adding more C-level-dangerous constructs to C++ without darn good reason. H=
alf-fixing variant and not actually fixing many _other_ major problems that=
 destructive move could solve (e.g., accidentally using a moved-from parame=
ter instead of the moved-to member in a class constructor).</p>
<p dir=3D"ltr">For three, your feature proposal opens whole new classes of =
mistakes than what we have today. The only mechanism even close to being as=
 dangerous is delete/free and modern C++ all but deprecates those features =
in user code, even in high-performance situations like AAA games. A &quot;g=
ood&quot; destructive move should _reduce_ errors in existing code -- like =
accidentally using moved-from values -- rather than adding new ones. Perfor=
mance alone isn&#39;t good enough. Remember, rvalue references _real_ goal =
was to allow us to replace things like the easy-to-misuse auto_ptr with the=
 much superior unique_ptr. The potential performance improvements of move s=
emantics were icing on the cake.</p>
<p dir=3D"ltr">Now let&#39;s be clear: the intent of relocation is good. We=
 need someone working on this, IMO. I&#39;m more than happy to see you work=
 on it; you seem like a pretty bright person and are obviously passionate a=
bout the issue. I just strongly think that the proposal you currently have =
just isn&#39;t &quot;there&quot; yet and needs more design iteration. :)</p=
>
<p dir=3D"ltr">&gt;<br>
</p>
</div>
</blockquote></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/4f31b957-05be-47cf-a1ca-03f33a9900c0%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/4f31b957-05be-47cf-a1ca-03f33a9900c0=
%40isocpp.org</a>.<br />

------=_Part_131_229753461.1460090294215--
------=_Part_130_2079848649.1460090294215--

.

------=_Part_109_456967907.1460092047539
Content-Type: multipart/alternative;
 boundary="----=_Part_110_337853907.1460092047539"

------=_Part_110_337853907.1460092047539
Content-Type: text/plain; charset=UTF-8

On Friday, April 8, 2016 at 12:38:14 AM UTC-4, isocp...@denisbider.com
wrote:
>
> Hey Sean,
>
> if you would like to see move destruction / relocation proposed in a safer
> form, do you have any ideas about what that safer form would look like?
>
> You refer to that modern C++ discourages direct use of new and delete.
> Well, yes, of course. But libraries still need to use new and delete, as
> well as placement new, to implement containers. How would you propose
> implementing the standard library without these features?
>
> It is not the intention of this Relocator proposal to be used directly by
> end users. The intention is that it would be used in STL implementations,
> to solve problems that a lack of destructive move makes difficult.
>
> Language users should not have to worry about invoking or implementing
> relocators, in much the same way they shouldn't have to worry about move
> constructors. Language users should use standard library types, and it's up
> to the library types to implement relocators and move constructors.
>

It's a nice fantasy to believe that the standard library can cover every
use case. Or that compiler-generated move constructors are sufficient. But
at the end of the day, it is little more than a fiction.

In the real world, people have to learn how to write move constructors.
Most C++ programmers have to do this. And they have to learn to write them
*correctly*.

Whatever your personal intention may be, if you add some form of
destructive move/relocation/whatever-you-want-to-call it, lots of C++
programmers are going to have to learn how to use it. They're going to have
to learn how to write destructive move operations and they're going to have
to learn how to invoke them. Correctly and safely.

You cannot just handwave away such issues.

--
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/66a44c9c-21f9-4854-81ab-37235408eb4f%40isocpp.org.

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

<div dir=3D"ltr">On Friday, April 8, 2016 at 12:38:14 AM UTC-4, isocp...@de=
nisbider.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D=
"ltr"><div>Hey Sean,</div><div><br></div><div>if you=C2=A0would like to see=
=C2=A0move destruction / relocation proposed in a safer form, do you have a=
ny ideas about what that safer form would look like?</div><div><br></div><d=
iv>You refer to that modern C++ discourages direct use of new and delete. W=
ell, yes, of course. But libraries still need to use new and delete,=C2=A0a=
s well as=C2=A0placement new,=C2=A0to implement containers. How would you p=
ropose implementing the standard library without these features?</div><div>=
<br></div><div>It is not the intention of this Relocator proposal to be use=
d directly by end users. The intention is that it would be used in STL impl=
ementations, to solve problems that a lack of destructive move makes diffic=
ult.</div><div><br></div><div>Language users should not have to worry about=
 invoking or implementing relocators, in much the same way they shouldn&#39=
;t have to worry about move constructors. Language users should use standar=
d library types, and it&#39;s up to the=20
library types to implement relocators and move constructors.</div></div></b=
lockquote><div><br>It&#39;s a nice fantasy to believe that the standard lib=
rary can cover every use case. Or that compiler-generated move constructors=
 are sufficient. But at the end of the day, it is little more than a fictio=
n.<br><br>In the real world, people have to learn how to write move constru=
ctors. Most C++ programmers have to do this. And they have to learn to writ=
e them <i>correctly</i>.<br><br>Whatever your personal intention may be, if=
 you add some form of destructive move/relocation/whatever-you-want-to-call=
 it, lots of C++ programmers are going to have to learn how to use it. They=
&#39;re going to have to learn how to write destructive move operations and=
 they&#39;re going to have to learn how to invoke them. Correctly and safel=
y.<br><br>You cannot just handwave away such issues.</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/66a44c9c-21f9-4854-81ab-37235408eb4f%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/66a44c9c-21f9-4854-81ab-37235408eb4f=
%40isocpp.org</a>.<br />

------=_Part_110_337853907.1460092047539--
------=_Part_109_456967907.1460092047539--

.

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

On Thu, Apr 7, 2016 at 9:38 PM,  <isocppgroup@denisbider.com> wrote:
> Hey Sean,
>
> if you would like to see move destruction / relocation proposed in a safer
> form, do you have any ideas about what that safer form would look like?

Not with great specifics, or else I'd have written a paper on this. :)

I'd imagine it'd have something to do with value categories. The ideal is
to ensure that the compiler can statically detect moved-from objects and
disable destructor execution and provide diagnostics when the variable is
used, unless reinitialized explicitly.

>
> You refer to that modern C++ discourages direct use of new and delete.
Well,
> yes, of course. But libraries still need to use new and delete, as well as
> placement new, to implement containers. How would you propose implementing

They need no such thing. They use allocators. Allocators then need to use
placement new (and never delete) in almost all cases, but that is deeply
separate from most user code. Very few C++ users have written custom
allocators. Or even custom containers.

> the standard library without these features?

You're forming strawmen. The standard library can be implemented purely
with compiler intrinsics for all it matters in this context.

>
> It is not the intention of this Relocator proposal to be used directly by
> end users. The intention is that it would be used in STL implementations,
to
> solve problems that a lack of destructive move makes difficult.

It's a partial solution (it solves a minor efficiency problem for vector
and... what else? we've already gone over how it doesn't fix variant) and
involves a new form of constructor, new defaulted function rules, and so
on. It's a ton of work to add to the standardese and a ton of work to
implement for exceedinly little pay-off and leaves us still needing
_another_ solution for the other problems that make users (not just a
handful of stdlib implementors) clamor for destructive move.

It'd be like adding an incomplete version of move semantics that just added
a new special syntax for move construction without also adding rvalue
references or the extended value categories.

Nobody has yet proven that we need to settle for a complicated
half-solution. So let's not settle. :)

>
> Language users should not have to worry about invoking or implementing
> relocators, in much the same way they shouldn't have to worry about move
> constructors. Language users should use standard library types, and it's
up
> to the library types to implement relocators and move constructors.

In which case, we just need a new type trait and some rules in the standard
containers, and _zero_ new language features. Which game engine stdlib
replacements have been doing for over a decade. :)

>
> If you have any ideas of how the proposed feature can be made safer, I
would
> love to hear about it.

My very rough ideas would be to study value categories and rules and find
the set of categories that allow for in-place object destruction and
marking an object as "expired" so that the compiler knows it doesn't have
to invoke destructors. This also ties into lifetimes, and possibly needs to
integrate with a more nuanced notion of object lifetime in C++ (and hence
possibly should be "bundled" with lifetime extension a la N4221
<https://isocpp.org/files/papers/N4221.pdf>)

No, that's not a complete idea. I'm not saying I have a magic solution. It
may well take _years_ to get any version of this right. If these things
were easy or obvious, C++98 would have been a perfect language that never
needed another revision ever again. :p

>
> However, this is not to be mistaken for a feature that end users should
> directly use.

Then it has no reason to be a heavy-weight feature requiring such extensive
compiler support. If it's just for stdlib implementors and stdlib types,
they can already offer relocation completely today as a point of QoI via
private type traits purely in library code. 100% guarantee it, as I
primarily use one that does just that.

However, it turns out that "stdlib only" is not actually useful because (a)
stdlib containers want to support user-provided types at full
functionality, (b) some users do still need to write new containers given
how anemic the stdlib is, and (c) relocation as you've proposed doesn't
solve any particularly interesting or complicated problems worth the burden
it imposes on implementors.

You should either make your proposal much simpler pure-library affair or
you should think bigger and try to solve a much larger set of the problems
that destructive move / relocation could be solving. What you have now is
heavy-weight but only solves a very mundane problem.

>
>
> On Wednesday, April 6, 2016 at 10:45:09 PM UTC-6, Sean Middleditch wrote:
>>
>>
>> On Apr 6, 2016 9:55 AM, <isocp...@denisbider.com> wrote:
>> >
>> > > The committee can mandate that standard library types all have
>> > > relocators added where necessary but it can do no such thing for
>> > > user types. However, the committee _does_ want to allow variant
>> > > to be used with those same problematic user types.
>> >
>> >
>> > With respect to variant, it is already a major advantage of relocation
>> > that it can support:
>> >
>> > - exception-safe use of variant with non-nullable standard library
types
>> > - without requiring an existing std::list implementation to be thrown
away
>> > so it can be nothrow_move_constructible;
>> >
>> > - exception-safe use of variant with future non-nullable types.
>>
>> But not "exception safe" for other types, meaning that it still requires
>> the work around with the valueless state. So we go from a "mostly never
>> empty" container to a "slightly more mostly never empty" container. :)
>>
>> >
>> >
>> > Existing problematic non-library types can of course still be
supported,
>> > if we're willing to lose the strong exception safety guarantee in that
case.
>> > I'm not sure there is a silver bullet that can avoid that.
>> >
>> >
>> > > With your proposal, it's way too easy to accidentally leave
>> > > some object in an undefined state
>> >
>> > I find this logic highly questionable. By this line of reasoning, we
>> > should remove placement new, C-style casts, and manual memory
management, so
>> > that C++ might become a managed language.
>>
>> Not at all, and that's quite the logical jump. For one, your feature
>> doesn't actually exist yet, while those others do; adding unsafe features
>> and keeping old unsafe features (that we actually _do_ kinda-sorta
>> deprecate, e.g. the modern advice to never ever use new/delete or C-style
>> casts) for back-compat are two very different things. :)
>>
>> For two, there are degrees of ease-of- misuse and not just a binary
>> equation of assembly vs C# :)  Rust for instance is a case of going too
far
>> with protecting users from mistakes and going straight into forcing
users to
>> jump through hoops to convince the compiler of the validity of perfectly
>> valid code. It errs completely on the side of safety. Nobody is
(seriously)
>> advocating that for C++. Neither should we be advocating to adding more
>> C-level-dangerous constructs to C++ without darn good reason. Half-fixing
>> variant and not actually fixing many _other_ major problems that
destructive
>> move could solve (e.g., accidentally using a moved-from parameter
instead of
>> the moved-to member in a class constructor).
>>
>> For three, your feature proposal opens whole new classes of mistakes than
>> what we have today. The only mechanism even close to being as dangerous
is
>> delete/free and modern C++ all but deprecates those features in user
code,
>> even in high-performance situations like AAA games. A "good" destructive
>> move should _reduce_ errors in existing code -- like accidentally using
>> moved-from values -- rather than adding new ones. Performance alone isn't
>> good enough. Remember, rvalue references _real_ goal was to allow us to
>> replace things like the easy-to-misuse auto_ptr with the much superior
>> unique_ptr. The potential performance improvements of move semantics were
>> icing on the cake.
>>
>> Now let's be clear: the intent of relocation is good. We need someone
>> working on this, IMO. I'm more than happy to see you work on it; you seem
>> like a pretty bright person and are obviously passionate about the
issue. I
>> just strongly think that the proposal you currently have just isn't
"there"
>> yet and needs more design iteration. :)
>>
>> >
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit
>
https://groups.google.com/a/isocpp.org/d/topic/std-proposals/jdY0hieE0E0/unsubscribe
..
> To unsubscribe from this group and all its topics, send an email to
> std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit
>
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/4f31b957-05be-47cf-a1ca-03f33a9900c0%40isocpp.org
..



--
Sean Middleditch
http://seanmiddleditch.com

--
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/CALQmNFgoV-Rg4T6%2BKqMFt6vNa7GCDpU%3DjVLRcnK4dDd%2BeBby8A%40mail.gmail.com.

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

<div dir=3D"ltr">On Thu, Apr 7, 2016 at 9:38 PM, =C2=A0&lt;<a href=3D"mailt=
o:isocppgroup@denisbider.com">isocppgroup@denisbider.com</a>&gt; wrote:<br>=
&gt; Hey Sean,<br>&gt;<br>&gt; if you would like to see move destruction / =
relocation proposed in a safer<br>&gt; form, do you have any ideas about wh=
at that safer form would look like?<br><br>Not with great specifics, or els=
e I&#39;d have written a paper on this. :)<br><br>I&#39;d imagine it&#39;d =
have something to do with value categories. The ideal is to ensure that the=
 compiler can statically detect moved-from objects and disable destructor e=
xecution and provide diagnostics when the variable is used, unless reinitia=
lized explicitly.<br><br>&gt;<br>&gt; You refer to that modern C++ discoura=
ges direct use of new and delete. Well,<br>&gt; yes, of course. But librari=
es still need to use new and delete, as well as<br>&gt; placement new, to i=
mplement containers. How would you propose implementing<br><br>They need no=
 such thing. They use allocators. Allocators then need to use placement new=
 (and never delete) in almost all cases, but that is deeply separate from m=
ost user code. Very few C++ users have written custom allocators. Or even c=
ustom containers.<br><br>&gt; the standard library without these features?<=
br><br>You&#39;re forming strawmen. The standard library can be implemented=
 purely with compiler intrinsics for all it matters in this context.<br><br=
>&gt;<br>&gt; It is not the intention of this Relocator proposal to be used=
 directly by<br>&gt; end users. The intention is that it would be used in S=
TL implementations, to<br>&gt; solve problems that a lack of destructive mo=
ve makes difficult.<br><br>It&#39;s a partial solution (it solves a minor e=
fficiency problem for vector and... what else? we&#39;ve already gone over =
how it doesn&#39;t fix variant) and involves a new form of constructor, new=
 defaulted function rules, and so on. It&#39;s a ton of work to add to the =
standardese and a ton of work to implement for exceedinly little pay-off an=
d leaves us still needing _another_ solution for the other problems that ma=
ke users (not just a handful of stdlib implementors) clamor for destructive=
 move.<br><br>It&#39;d be like adding an incomplete version of move semanti=
cs that just added a new special syntax for move construction without also =
adding rvalue references or the extended value categories.<br><br>Nobody ha=
s yet proven that we need to settle for a complicated half-solution. So let=
&#39;s not settle. :)<br><br>&gt;<br>&gt; Language users should not have to=
 worry about invoking or implementing<br>&gt; relocators, in much the same =
way they shouldn&#39;t have to worry about move<br>&gt; constructors. Langu=
age users should use standard library types, and it&#39;s up<br>&gt; to the=
 library types to implement relocators and move constructors.<br><br>In whi=
ch case, we just need a new type trait and some rules in the standard conta=
iners, and _zero_ new language features. Which game engine stdlib replaceme=
nts have been doing for over a decade. :)<br><br>&gt;<br>&gt; If you have a=
ny ideas of how the proposed feature can be made safer, I would<br>&gt; lov=
e to hear about it.<br><br>My very rough ideas would be to study value cate=
gories and rules and find the set of categories that allow for in-place obj=
ect destruction and marking an object as &quot;expired&quot; so that the co=
mpiler knows it doesn&#39;t have to invoke destructors. This also ties into=
 lifetimes, and possibly needs to integrate with a more nuanced notion of o=
bject lifetime in C++ (and hence possibly should be &quot;bundled&quot; wit=
h lifetime extension a la <a href=3D"https://isocpp.org/files/papers/N4221.=
pdf">N4221</a>)<br><br>No, that&#39;s not a complete idea. I&#39;m not sayi=
ng I have a magic solution. It may well take _years_ to get any version of =
this right. If these things were easy or obvious, C++98 would have been a p=
erfect language that never needed another revision ever again. :p<div><br><=
/div><div>&gt;<br>&gt; However, this is not to be mistaken for a feature th=
at end users should<br>&gt; directly use.<br><br>Then it has no reason to b=
e a heavy-weight feature requiring such extensive compiler support. If it&#=
39;s just for stdlib implementors and stdlib types, they can already offer =
relocation completely today as a point of QoI via private type traits purel=
y in library code. 100% guarantee it, as I primarily use one that does just=
 that.<br><br>However, it turns out that &quot;stdlib only&quot; is not act=
ually useful because (a) stdlib containers want to support user-provided ty=
pes at full functionality, (b) some users do still need to write new contai=
ners given how anemic the stdlib is, and (c) relocation as you&#39;ve propo=
sed doesn&#39;t solve any particularly interesting or complicated problems =
worth the burden it imposes on implementors.<br><br>You should either make =
your proposal much simpler pure-library affair or you should think bigger a=
nd try to solve a much larger set of the problems that destructive move / r=
elocation could be solving. What you have now is heavy-weight but only solv=
es a very mundane problem.<br><br>&gt;<br>&gt;<br>&gt; On Wednesday, April =
6, 2016 at 10:45:09 PM UTC-6, Sean Middleditch wrote:<br>&gt;&gt;<br>&gt;&g=
t;<br>&gt;&gt; On Apr 6, 2016 9:55 AM, &lt;<a href=3D"mailto:isocp...@denis=
bider.com">isocp...@denisbider.com</a>&gt; wrote:<br>&gt;&gt; &gt;<br>&gt;&=
gt; &gt; &gt; The committee can mandate that standard library types all hav=
e<br>&gt;&gt; &gt; &gt; relocators added where necessary but it can do no s=
uch thing for<br>&gt;&gt; &gt; &gt; user types. However, the committee _doe=
s_ want to allow variant<br>&gt;&gt; &gt; &gt; to be used with those same p=
roblematic user types.<br>&gt;&gt; &gt;<br>&gt;&gt; &gt;<br>&gt;&gt; &gt; W=
ith respect to variant, it is already a major advantage of relocation<br>&g=
t;&gt; &gt; that it can support:<br>&gt;&gt; &gt;<br>&gt;&gt; &gt; - except=
ion-safe use of variant with non-nullable standard library types<br>&gt;&gt=
; &gt; - without requiring an existing std::list implementation to be throw=
n away<br>&gt;&gt; &gt; so it can be nothrow_move_constructible;<br>&gt;&gt=
; &gt;<br>&gt;&gt; &gt; - exception-safe use of variant with future non-nul=
lable types.<br>&gt;&gt;<br>&gt;&gt; But not &quot;exception safe&quot; for=
 other types, meaning that it still requires<br>&gt;&gt; the work around wi=
th the valueless state. So we go from a &quot;mostly never<br>&gt;&gt; empt=
y&quot; container to a &quot;slightly more mostly never empty&quot; contain=
er. :)<br>&gt;&gt;<br>&gt;&gt; &gt;<br>&gt;&gt; &gt;<br>&gt;&gt; &gt; Exist=
ing problematic non-library types can of course still be supported,<br>&gt;=
&gt; &gt; if we&#39;re willing to lose the strong exception safety guarante=
e in that case.<br>&gt;&gt; &gt; I&#39;m not sure there is a silver bullet =
that can avoid that.<br>&gt;&gt; &gt;<br>&gt;&gt; &gt;<br>&gt;&gt; &gt; &gt=
; With your proposal, it&#39;s way too easy to accidentally leave<br>&gt;&g=
t; &gt; &gt; some object in an undefined state<br>&gt;&gt; &gt;<br>&gt;&gt;=
 &gt; I find this logic highly questionable. By this line of reasoning, we<=
br>&gt;&gt; &gt; should remove placement new, C-style casts, and manual mem=
ory management, so<br>&gt;&gt; &gt; that C++ might become a managed languag=
e.<br>&gt;&gt;<br>&gt;&gt; Not at all, and that&#39;s quite the logical jum=
p. For one, your feature<br>&gt;&gt; doesn&#39;t actually exist yet, while =
those others do; adding unsafe features<br>&gt;&gt; and keeping old unsafe =
features (that we actually _do_ kinda-sorta<br>&gt;&gt; deprecate, e.g. the=
 modern advice to never ever use new/delete or C-style<br>&gt;&gt; casts) f=
or back-compat are two very different things. :)<br>&gt;&gt;<br>&gt;&gt; Fo=
r two, there are degrees of ease-of- misuse and not just a binary<br>&gt;&g=
t; equation of assembly vs C# :) =C2=A0Rust for instance is a case of going=
 too far<br>&gt;&gt; with protecting users from mistakes and going straight=
 into forcing users to<br>&gt;&gt; jump through hoops to convince the compi=
ler of the validity of perfectly<br>&gt;&gt; valid code. It errs completely=
 on the side of safety. Nobody is (seriously)<br>&gt;&gt; advocating that f=
or C++. Neither should we be advocating to adding more<br>&gt;&gt; C-level-=
dangerous constructs to C++ without darn good reason. Half-fixing<br>&gt;&g=
t; variant and not actually fixing many _other_ major problems that destruc=
tive<br>&gt;&gt; move could solve (e.g., accidentally using a moved-from pa=
rameter instead of<br>&gt;&gt; the moved-to member in a class constructor).=
<br>&gt;&gt;<br>&gt;&gt; For three, your feature proposal opens whole new c=
lasses of mistakes than<br>&gt;&gt; what we have today. The only mechanism =
even close to being as dangerous is<br>&gt;&gt; delete/free and modern C++ =
all but deprecates those features in user code,<br>&gt;&gt; even in high-pe=
rformance situations like AAA games. A &quot;good&quot; destructive<br>&gt;=
&gt; move should _reduce_ errors in existing code -- like accidentally usin=
g<br>&gt;&gt; moved-from values -- rather than adding new ones. Performance=
 alone isn&#39;t<br>&gt;&gt; good enough. Remember, rvalue references _real=
_ goal was to allow us to<br>&gt;&gt; replace things like the easy-to-misus=
e auto_ptr with the much superior<br>&gt;&gt; unique_ptr. The potential per=
formance improvements of move semantics were<br>&gt;&gt; icing on the cake.=
<br>&gt;&gt;<br>&gt;&gt; Now let&#39;s be clear: the intent of relocation i=
s good. We need someone<br>&gt;&gt; working on this, IMO. I&#39;m more than=
 happy to see you work on it; you seem<br>&gt;&gt; like a pretty bright per=
son and are obviously passionate about the issue. I<br>&gt;&gt; just strong=
ly think that the proposal you currently have just isn&#39;t &quot;there&qu=
ot;<br>&gt;&gt; yet and needs more design iteration. :)<br>&gt;&gt;<br>&gt;=
&gt; &gt;<br>&gt;<br>&gt; --<br>&gt; You received this message because you =
are subscribed to a topic in the<br>&gt; Google Groups &quot;ISO C++ Standa=
rd - Future Proposals&quot; group.<br>&gt; To unsubscribe from this topic, =
visit<br>&gt; <a href=3D"https://groups.google.com/a/isocpp.org/d/topic/std=
-proposals/jdY0hieE0E0/unsubscribe">https://groups.google.com/a/isocpp.org/=
d/topic/std-proposals/jdY0hieE0E0/unsubscribe</a>.<br>&gt; To unsubscribe f=
rom this group and all its topics, send an email to<br>&gt; <a href=3D"mail=
to:std-proposals%2Bunsubscribe@isocpp.org">std-proposals+unsubscribe@isocpp=
..org</a>.<br>&gt; To post to this group, send email to <a href=3D"mailto:st=
d-proposals@isocpp.org">std-proposals@isocpp.org</a>.<br>&gt; To view this =
discussion on the web visit<br>&gt; <a href=3D"https://groups.google.com/a/=
isocpp.org/d/msgid/std-proposals/4f31b957-05be-47cf-a1ca-03f33a9900c0%40iso=
cpp.org">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/4f31b=
957-05be-47cf-a1ca-03f33a9900c0%40isocpp.org</a>.<br><br><br><br>-- <br>Sea=
n Middleditch<br><a href=3D"http://seanmiddleditch.com">http://seanmiddledi=
tch.com</a></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/CALQmNFgoV-Rg4T6%2BKqMFt6vNa7GCDpU%3D=
jVLRcnK4dDd%2BeBby8A%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALQmNFgoV-=
Rg4T6%2BKqMFt6vNa7GCDpU%3DjVLRcnK4dDd%2BeBby8A%40mail.gmail.com</a>.<br />

--001a113dc8ba4cbd21052ff23566--

.

------=_Part_150_1744017611.1460095636653
Content-Type: multipart/alternative;
 boundary="----=_Part_151_941910145.1460095636654"

------=_Part_151_941910145.1460095636654
Content-Type: text/plain; charset=UTF-8

Ah, Jesus.

It seems to me C++ has become infested with people who call themselves
"modern", but whose objective is to desperately try to divorce the
language from its low-level origins, while ashamedly having to recognize
that this cannot be done, because it would defeat the purpose of the
language and make it useless for its primary role.

You are now building this over-ambitious standard library monstrosity,
which is trying to pretend that C++ can be a platform. But the role of C++
is not to *be* a platform. It is a tool for *building* platforms, and for
building applications on top of existing platforms.

I can honestly say I don't like what you're doing, and if you keep going in
this direction, C++ will have to be replaced with something that serves its
original purpose.

Stop trying to make this a managed language, for god's sake.


On Thursday, April 7, 2016 at 11:10:08 PM UTC-6, Sean Middleditch wrote:

> On Thu, Apr 7, 2016 at 9:38 PM,  <isocp...@denisbider.com <javascript:>>
> wrote:
> > Hey Sean,
> >
> > if you would like to see move destruction / relocation proposed in a
> safer
> > form, do you have any ideas about what that safer form would look like?
>
> Not with great specifics, or else I'd have written a paper on this. :)
>
> I'd imagine it'd have something to do with value categories. The ideal is
> to ensure that the compiler can statically detect moved-from objects and
> disable destructor execution and provide diagnostics when the variable is
> used, unless reinitialized explicitly.
>
> >
> > You refer to that modern C++ discourages direct use of new and delete.
> Well,
> > yes, of course. But libraries still need to use new and delete, as well
> as
> > placement new, to implement containers. How would you propose
> implementing
>
> They need no such thing. They use allocators. Allocators then need to use
> placement new (and never delete) in almost all cases, but that is deeply
> separate from most user code. Very few C++ users have written custom
> allocators. Or even custom containers.
>
> > the standard library without these features?
>
> You're forming strawmen. The standard library can be implemented purely
> with compiler intrinsics for all it matters in this context.
>
> >
> > It is not the intention of this Relocator proposal to be used directly by
> > end users. The intention is that it would be used in STL
> implementations, to
> > solve problems that a lack of destructive move makes difficult.
>
> It's a partial solution (it solves a minor efficiency problem for vector
> and... what else? we've already gone over how it doesn't fix variant) and
> involves a new form of constructor, new defaulted function rules, and so
> on. It's a ton of work to add to the standardese and a ton of work to
> implement for exceedinly little pay-off and leaves us still needing
> _another_ solution for the other problems that make users (not just a
> handful of stdlib implementors) clamor for destructive move.
>
> It'd be like adding an incomplete version of move semantics that just
> added a new special syntax for move construction without also adding rvalue
> references or the extended value categories.
>
> Nobody has yet proven that we need to settle for a complicated
> half-solution. So let's not settle. :)
>
> >
> > Language users should not have to worry about invoking or implementing
> > relocators, in much the same way they shouldn't have to worry about move
> > constructors. Language users should use standard library types, and it's
> up
> > to the library types to implement relocators and move constructors.
>
> In which case, we just need a new type trait and some rules in the
> standard containers, and _zero_ new language features. Which game engine
> stdlib replacements have been doing for over a decade. :)
>
> >
> > If you have any ideas of how the proposed feature can be made safer, I
> would
> > love to hear about it.
>
> My very rough ideas would be to study value categories and rules and find
> the set of categories that allow for in-place object destruction and
> marking an object as "expired" so that the compiler knows it doesn't have
> to invoke destructors. This also ties into lifetimes, and possibly needs to
> integrate with a more nuanced notion of object lifetime in C++ (and hence
> possibly should be "bundled" with lifetime extension a la N4221
> <https://isocpp.org/files/papers/N4221.pdf>)
>
> No, that's not a complete idea. I'm not saying I have a magic solution. It
> may well take _years_ to get any version of this right. If these things
> were easy or obvious, C++98 would have been a perfect language that never
> needed another revision ever again. :p
>
> >
> > However, this is not to be mistaken for a feature that end users should
> > directly use.
>
> Then it has no reason to be a heavy-weight feature requiring such
> extensive compiler support. If it's just for stdlib implementors and stdlib
> types, they can already offer relocation completely today as a point of QoI
> via private type traits purely in library code. 100% guarantee it, as I
> primarily use one that does just that.
>
> However, it turns out that "stdlib only" is not actually useful because
> (a) stdlib containers want to support user-provided types at full
> functionality, (b) some users do still need to write new containers given
> how anemic the stdlib is, and (c) relocation as you've proposed doesn't
> solve any particularly interesting or complicated problems worth the burden
> it imposes on implementors.
>
> You should either make your proposal much simpler pure-library affair or
> you should think bigger and try to solve a much larger set of the problems
> that destructive move / relocation could be solving. What you have now is
> heavy-weight but only solves a very mundane problem.
>
> >
> >
> > On Wednesday, April 6, 2016 at 10:45:09 PM UTC-6, Sean Middleditch wrote:
> >>
> >>
> >> On Apr 6, 2016 9:55 AM, <isocp...@denisbider.com> wrote:
> >> >
> >> > > The committee can mandate that standard library types all have
> >> > > relocators added where necessary but it can do no such thing for
> >> > > user types. However, the committee _does_ want to allow variant
> >> > > to be used with those same problematic user types.
> >> >
> >> >
> >> > With respect to variant, it is already a major advantage of relocation
> >> > that it can support:
> >> >
> >> > - exception-safe use of variant with non-nullable standard library
> types
> >> > - without requiring an existing std::list implementation to be thrown
> away
> >> > so it can be nothrow_move_constructible;
> >> >
> >> > - exception-safe use of variant with future non-nullable types.
> >>
> >> But not "exception safe" for other types, meaning that it still requires
> >> the work around with the valueless state. So we go from a "mostly never
> >> empty" container to a "slightly more mostly never empty" container. :)
> >>
> >> >
> >> >
> >> > Existing problematic non-library types can of course still be
> supported,
> >> > if we're willing to lose the strong exception safety guarantee in
> that case.
> >> > I'm not sure there is a silver bullet that can avoid that.
> >> >
> >> >
> >> > > With your proposal, it's way too easy to accidentally leave
> >> > > some object in an undefined state
> >> >
> >> > I find this logic highly questionable. By this line of reasoning, we
> >> > should remove placement new, C-style casts, and manual memory
> management, so
> >> > that C++ might become a managed language.
> >>
> >> Not at all, and that's quite the logical jump. For one, your feature
> >> doesn't actually exist yet, while those others do; adding unsafe
> features
> >> and keeping old unsafe features (that we actually _do_ kinda-sorta
> >> deprecate, e.g. the modern advice to never ever use new/delete or
> C-style
> >> casts) for back-compat are two very different things. :)
> >>
> >> For two, there are degrees of ease-of- misuse and not just a binary
> >> equation of assembly vs C# :)  Rust for instance is a case of going too
> far
> >> with protecting users from mistakes and going straight into forcing
> users to
> >> jump through hoops to convince the compiler of the validity of perfectly
> >> valid code. It errs completely on the side of safety. Nobody is
> (seriously)
> >> advocating that for C++. Neither should we be advocating to adding more
> >> C-level-dangerous constructs to C++ without darn good reason.
> Half-fixing
> >> variant and not actually fixing many _other_ major problems that
> destructive
> >> move could solve (e.g., accidentally using a moved-from parameter
> instead of
> >> the moved-to member in a class constructor).
> >>
> >> For three, your feature proposal opens whole new classes of mistakes
> than
> >> what we have today. The only mechanism even close to being as dangerous
> is
> >> delete/free and modern C++ all but deprecates those features in user
> code,
> >> even in high-performance situations like AAA games. A "good" destructive
> >> move should _reduce_ errors in existing code -- like accidentally using
> >> moved-from values -- rather than adding new ones. Performance alone
> isn't
> >> good enough. Remember, rvalue references _real_ goal was to allow us to
> >> replace things like the easy-to-misuse auto_ptr with the much superior
> >> unique_ptr. The potential performance improvements of move semantics
> were
> >> icing on the cake.
> >>
> >> Now let's be clear: the intent of relocation is good. We need someone
> >> working on this, IMO. I'm more than happy to see you work on it; you
> seem
> >> like a pretty bright person and are obviously passionate about the
> issue. I
> >> just strongly think that the proposal you currently have just isn't
> "there"
> >> yet and needs more design iteration. :)
> >>
> >> >
> >
> > --
> > You received this message because you are subscribed to a topic in the
> > Google Groups "ISO C++ Standard - Future Proposals" group.
> > To unsubscribe from this topic, visit
> >
> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/jdY0hieE0E0/unsubscribe
> .
> > To unsubscribe from this group and all its topics, send an email to
> > std-proposal...@isocpp.org <javascript:>.
> > To post to this group, send email to std-pr...@isocpp.org <javascript:>.
> > To view this discussion on the web visit
> >
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/4f31b957-05be-47cf-a1ca-03f33a9900c0%40isocpp.org
> .
>
>
>
> --
> Sean Middleditch
> http://seanmiddleditch.com
>

--
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/30181f63-7189-494d-9294-3f8b8759308f%40isocpp.org.

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

<div dir=3D"ltr"><div>Ah, Jesus.</div><div><br></div><div>It seems to me C+=
+ has become infested with people=C2=A0who call themselves &quot;modern&quo=
t;, but whose=C2=A0objective is to=C2=A0desperately try to divorce=C2=A0the=
 language=C2=A0from its low-level origins, while=C2=A0ashamedly having to=
=C2=A0recognize that this cannot be done, because it would defeat the purpo=
se of the language and make it useless for its primary role.</div><div><br>=
</div><div>You are now building this over-ambitious standard library monstr=
osity, which is=C2=A0trying to pretend that C++ can be a platform. But the=
=C2=A0role of C++ is not to <em>be</em> a platform. It is a tool for <em>bu=
ilding</em> platforms, and for building applications on top of existing pla=
tforms.</div><div><br></div><div>I can honestly say I don&#39;t like what y=
ou&#39;re doing, and if you keep going in this direction, C++ will have to =
be replaced with something that serves its original purpose.</div><div><br>=
</div><div>Stop trying to make this a managed language, for god&#39;s sake.=
</div><div><br><br>On Thursday, April 7, 2016 at 11:10:08 PM UTC-6, Sean Mi=
ddleditch wrote:</div><blockquote class=3D"gmail_quote" style=3D"margin: 0p=
x 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); =
border-left-width: 1px; border-left-style: solid;"><div dir=3D"ltr">On Thu,=
 Apr 7, 2016 at 9:38 PM, =C2=A0&lt;<a onmousedown=3D"this.href=3D&#39;javas=
cript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;retu=
rn true;" href=3D"javascript:" target=3D"_blank" rel=3D"nofollow" gdf-obfus=
cated-mailto=3D"8bzX3_53AgAJ">isocp...@denisbider.com</a>&gt; wrote:<br>&gt=
; Hey Sean,<br>&gt;<br>&gt; if you would like to see move destruction / rel=
ocation proposed in a safer<br>&gt; form, do you have any ideas about what =
that safer form would look like?<br><br>Not with great specifics, or else I=
&#39;d have written a paper on this. :)<br><br>I&#39;d imagine it&#39;d hav=
e something to do with value categories. The ideal is to ensure that the co=
mpiler can statically detect moved-from objects and disable destructor exec=
ution and provide diagnostics when the variable is used, unless reinitializ=
ed explicitly.<br><br>&gt;<br>&gt; You refer to that modern C++ discourages=
 direct use of new and delete. Well,<br>&gt; yes, of course. But libraries =
still need to use new and delete, as well as<br>&gt; placement new, to impl=
ement containers. How would you propose implementing<br><br>They need no su=
ch thing. They use allocators. Allocators then need to use placement new (a=
nd never delete) in almost all cases, but that is deeply separate from most=
 user code. Very few C++ users have written custom allocators. Or even cust=
om containers.<br><br>&gt; the standard library without these features?<br>=
<br>You&#39;re forming strawmen. The standard library can be implemented pu=
rely with compiler intrinsics for all it matters in this context.<br><br>&g=
t;<br>&gt; It is not the intention of this Relocator proposal to be used di=
rectly by<br>&gt; end users. The intention is that it would be used in STL =
implementations, to<br>&gt; solve problems that a lack of destructive move =
makes difficult.<br><br>It&#39;s a partial solution (it solves a minor effi=
ciency problem for vector and... what else? we&#39;ve already gone over how=
 it doesn&#39;t fix variant) and involves a new form of constructor, new de=
faulted function rules, and so on. It&#39;s a ton of work to add to the sta=
ndardese and a ton of work to implement for exceedinly little pay-off and l=
eaves us still needing _another_ solution for the other problems that make =
users (not just a handful of stdlib implementors) clamor for destructive mo=
ve.<br><br>It&#39;d be like adding an incomplete version of move semantics =
that just added a new special syntax for move construction without also add=
ing rvalue references or the extended value categories.<br><br>Nobody has y=
et proven that we need to settle for a complicated half-solution. So let&#3=
9;s not settle. :)<br><br>&gt;<br>&gt; Language users should not have to wo=
rry about invoking or implementing<br>&gt; relocators, in much the same way=
 they shouldn&#39;t have to worry about move<br>&gt; constructors. Language=
 users should use standard library types, and it&#39;s up<br>&gt; to the li=
brary types to implement relocators and move constructors.<br><br>In which =
case, we just need a new type trait and some rules in the standard containe=
rs, and _zero_ new language features. Which game engine stdlib replacements=
 have been doing for over a decade. :)<br><br>&gt;<br>&gt; If you have any =
ideas of how the proposed feature can be made safer, I would<br>&gt; love t=
o hear about it.<br><br>My very rough ideas would be to study value categor=
ies and rules and find the set of categories that allow for in-place object=
 destruction and marking an object as &quot;expired&quot; so that the compi=
ler knows it doesn&#39;t have to invoke destructors. This also ties into li=
fetimes, and possibly needs to integrate with a more nuanced notion of obje=
ct lifetime in C++ (and hence possibly should be &quot;bundled&quot; with l=
ifetime extension a la <a onmousedown=3D"this.href=3D&#39;https://www.googl=
e.com/url?q\75https%3A%2F%2Fisocpp.org%2Ffiles%2Fpapers%2FN4221.pdf\46sa\75=
D\46sntz\0751\46usg\75AFQjCNEo6r7YvYOoKPOk-oK52v7NQFuPRg&#39;;return true;"=
 onclick=3D"this.href=3D&#39;https://www.google.com/url?q\75https%3A%2F%2Fi=
socpp.org%2Ffiles%2Fpapers%2FN4221.pdf\46sa\75D\46sntz\0751\46usg\75AFQjCNE=
o6r7YvYOoKPOk-oK52v7NQFuPRg&#39;;return true;" href=3D"https://isocpp.org/f=
iles/papers/N4221.pdf" target=3D"_blank" rel=3D"nofollow">N4221</a>)<br><br=
>No, that&#39;s not a complete idea. I&#39;m not saying I have a magic solu=
tion. It may well take _years_ to get any version of this right. If these t=
hings were easy or obvious, C++98 would have been a perfect language that n=
ever needed another revision ever again. :p<div><br></div><div>&gt;<br>&gt;=
 However, this is not to be mistaken for a feature that end users should<br=
>&gt; directly use.<br><br>Then it has no reason to be a heavy-weight featu=
re requiring such extensive compiler support. If it&#39;s just for stdlib i=
mplementors and stdlib types, they can already offer relocation completely =
today as a point of QoI via private type traits purely in library code. 100=
% guarantee it, as I primarily use one that does just that.<br><br>However,=
 it turns out that &quot;stdlib only&quot; is not actually useful because (=
a) stdlib containers want to support user-provided types at full functional=
ity, (b) some users do still need to write new containers given how anemic =
the stdlib is, and (c) relocation as you&#39;ve proposed doesn&#39;t solve =
any particularly interesting or complicated problems worth the burden it im=
poses on implementors.<br><br>You should either make your proposal much sim=
pler pure-library affair or you should think bigger and try to solve a much=
 larger set of the problems that destructive move / relocation could be sol=
ving. What you have now is heavy-weight but only solves a very mundane prob=
lem.<br><br>&gt;<br>&gt;<br>&gt; On Wednesday, April 6, 2016 at 10:45:09 PM=
 UTC-6, Sean Middleditch wrote:<br>&gt;&gt;<br>&gt;&gt;<br>&gt;&gt; On Apr =
6, 2016 9:55 AM, &lt;<a>isocp...@denisbider.com</a>&gt; wrote:<br>&gt;&gt; =
&gt;<br>&gt;&gt; &gt; &gt; The committee can mandate that standard library =
types all have<br>&gt;&gt; &gt; &gt; relocators added where necessary but i=
t can do no such thing for<br>&gt;&gt; &gt; &gt; user types. However, the c=
ommittee _does_ want to allow variant<br>&gt;&gt; &gt; &gt; to be used with=
 those same problematic user types.<br>&gt;&gt; &gt;<br>&gt;&gt; &gt;<br>&g=
t;&gt; &gt; With respect to variant, it is already a major advantage of rel=
ocation<br>&gt;&gt; &gt; that it can support:<br>&gt;&gt; &gt;<br>&gt;&gt; =
&gt; - exception-safe use of variant with non-nullable standard library typ=
es<br>&gt;&gt; &gt; - without requiring an existing std::list implementatio=
n to be thrown away<br>&gt;&gt; &gt; so it can be nothrow_move_constructibl=
e;<br>&gt;&gt; &gt;<br>&gt;&gt; &gt; - exception-safe use of variant with f=
uture non-nullable types.<br>&gt;&gt;<br>&gt;&gt; But not &quot;exception s=
afe&quot; for other types, meaning that it still requires<br>&gt;&gt; the w=
ork around with the valueless state. So we go from a &quot;mostly never<br>=
&gt;&gt; empty&quot; container to a &quot;slightly more mostly never empty&=
quot; container. :)<br>&gt;&gt;<br>&gt;&gt; &gt;<br>&gt;&gt; &gt;<br>&gt;&g=
t; &gt; Existing problematic non-library types can of course still be suppo=
rted,<br>&gt;&gt; &gt; if we&#39;re willing to lose the strong exception sa=
fety guarantee in that case.<br>&gt;&gt; &gt; I&#39;m not sure there is a s=
ilver bullet that can avoid that.<br>&gt;&gt; &gt;<br>&gt;&gt; &gt;<br>&gt;=
&gt; &gt; &gt; With your proposal, it&#39;s way too easy to accidentally le=
ave<br>&gt;&gt; &gt; &gt; some object in an undefined state<br>&gt;&gt; &gt=
;<br>&gt;&gt; &gt; I find this logic highly questionable. By this line of r=
easoning, we<br>&gt;&gt; &gt; should remove placement new, C-style casts, a=
nd manual memory management, so<br>&gt;&gt; &gt; that C++ might become a ma=
naged language.<br>&gt;&gt;<br>&gt;&gt; Not at all, and that&#39;s quite th=
e logical jump. For one, your feature<br>&gt;&gt; doesn&#39;t actually exis=
t yet, while those others do; adding unsafe features<br>&gt;&gt; and keepin=
g old unsafe features (that we actually _do_ kinda-sorta<br>&gt;&gt; deprec=
ate, e.g. the modern advice to never ever use new/delete or C-style<br>&gt;=
&gt; casts) for back-compat are two very different things. :)<br>&gt;&gt;<b=
r>&gt;&gt; For two, there are degrees of ease-of- misuse and not just a bin=
ary<br>&gt;&gt; equation of assembly vs C# :) =C2=A0Rust for instance is a =
case of going too far<br>&gt;&gt; with protecting users from mistakes and g=
oing straight into forcing users to<br>&gt;&gt; jump through hoops to convi=
nce the compiler of the validity of perfectly<br>&gt;&gt; valid code. It er=
rs completely on the side of safety. Nobody is (seriously)<br>&gt;&gt; advo=
cating that for C++. Neither should we be advocating to adding more<br>&gt;=
&gt; C-level-dangerous constructs to C++ without darn good reason. Half-fix=
ing<br>&gt;&gt; variant and not actually fixing many _other_ major problems=
 that destructive<br>&gt;&gt; move could solve (e.g., accidentally using a =
moved-from parameter instead of<br>&gt;&gt; the moved-to member in a class =
constructor).<br>&gt;&gt;<br>&gt;&gt; For three, your feature proposal open=
s whole new classes of mistakes than<br>&gt;&gt; what we have today. The on=
ly mechanism even close to being as dangerous is<br>&gt;&gt; delete/free an=
d modern C++ all but deprecates those features in user code,<br>&gt;&gt; ev=
en in high-performance situations like AAA games. A &quot;good&quot; destru=
ctive<br>&gt;&gt; move should _reduce_ errors in existing code -- like acci=
dentally using<br>&gt;&gt; moved-from values -- rather than adding new ones=
.. Performance alone isn&#39;t<br>&gt;&gt; good enough. Remember, rvalue ref=
erences _real_ goal was to allow us to<br>&gt;&gt; replace things like the =
easy-to-misuse auto_ptr with the much superior<br>&gt;&gt; unique_ptr. The =
potential performance improvements of move semantics were<br>&gt;&gt; icing=
 on the cake.<br>&gt;&gt;<br>&gt;&gt; Now let&#39;s be clear: the intent of=
 relocation is good. We need someone<br>&gt;&gt; working on this, IMO. I&#3=
9;m more than happy to see you work on it; you seem<br>&gt;&gt; like a pret=
ty bright person and are obviously passionate about the issue. I<br>&gt;&gt=
; just strongly think that the proposal you currently have just isn&#39;t &=
quot;there&quot;<br>&gt;&gt; yet and needs more design iteration. :)<br>&gt=
;&gt;<br>&gt;&gt; &gt;<br>&gt;<br>&gt; --<br>&gt; You received this message=
 because you are subscribed to a topic in the<br>&gt; Google Groups &quot;I=
SO C++ Standard - Future Proposals&quot; group.<br>&gt; To unsubscribe from=
 this topic, visit<br>&gt; <a onmousedown=3D"this.href=3D&#39;https://group=
s.google.com/a/isocpp.org/d/topic/std-proposals/jdY0hieE0E0/unsubscribe&#39=
;;return true;" onclick=3D"this.href=3D&#39;https://groups.google.com/a/iso=
cpp.org/d/topic/std-proposals/jdY0hieE0E0/unsubscribe&#39;;return true;" hr=
ef=3D"https://groups.google.com/a/isocpp.org/d/topic/std-proposals/jdY0hieE=
0E0/unsubscribe" target=3D"_blank" rel=3D"nofollow">https://groups.google.c=
om/a/<wbr>isocpp.org/d/topic/std-<wbr>proposals/jdY0hieE0E0/<wbr>unsubscrib=
e</a>.<br>&gt; To unsubscribe from this group and all its topics, send an e=
mail to<br>&gt; <a onmousedown=3D"this.href=3D&#39;javascript:&#39;;return =
true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true;" href=3D"j=
avascript:" target=3D"_blank" rel=3D"nofollow" gdf-obfuscated-mailto=3D"8bz=
X3_53AgAJ">std-proposal...@<wbr>isocpp.org</a>.<br>&gt; To post to this gro=
up, send email to <a onmousedown=3D"this.href=3D&#39;javascript:&#39;;retur=
n true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true;" href=3D=
"javascript:" target=3D"_blank" rel=3D"nofollow" gdf-obfuscated-mailto=3D"8=
bzX3_53AgAJ">std-pr...@isocpp.org</a>.<br>&gt; To view this discussion on t=
he web visit<br>&gt; <a onmousedown=3D"this.href=3D&#39;https://groups.goog=
le.com/a/isocpp.org/d/msgid/std-proposals/4f31b957-05be-47cf-a1ca-03f33a990=
0c0%40isocpp.org&#39;;return true;" onclick=3D"this.href=3D&#39;https://gro=
ups.google.com/a/isocpp.org/d/msgid/std-proposals/4f31b957-05be-47cf-a1ca-0=
3f33a9900c0%40isocpp.org&#39;;return true;" href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/4f31b957-05be-47cf-a1ca-03f33a9900c0%=
40isocpp.org" target=3D"_blank" rel=3D"nofollow">https://groups.google.com/=
a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/4f31b957-05be-47cf-<wbr>a1ca-0=
3f33a9900c0%40isocpp.org</a><wbr>.<br><br><br><br>-- <br>Sean Middleditch<b=
r><a onmousedown=3D"this.href=3D&#39;http://www.google.com/url?q\75http%3A%=
2F%2Fseanmiddleditch.com\46sa\75D\46sntz\0751\46usg\75AFQjCNHx3WLavT-kbToOv=
7IL4uvcN5l-vg&#39;;return true;" onclick=3D"this.href=3D&#39;http://www.goo=
gle.com/url?q\75http%3A%2F%2Fseanmiddleditch.com\46sa\75D\46sntz\0751\46usg=
\75AFQjCNHx3WLavT-kbToOv7IL4uvcN5l-vg&#39;;return true;" href=3D"http://sea=
nmiddleditch.com" target=3D"_blank" rel=3D"nofollow">http://seanmiddleditch=
..com</a></div></div>
</blockquote></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/30181f63-7189-494d-9294-3f8b8759308f%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/30181f63-7189-494d-9294-3f8b8759308f=
%40isocpp.org</a>.<br />

------=_Part_151_941910145.1460095636654--
------=_Part_150_1744017611.1460095636653--

.

------=_Part_6_378321275.1460099938908
Content-Type: multipart/alternative;
 boundary="----=_Part_7_518778252.1460099938909"

------=_Part_7_518778252.1460099938909
Content-Type: text/plain; charset=UTF-8

Let me expand on this. In doing so, I hope to help you guys understand the
developer audience that, in the name of "modernity", you are alienating.

The key value of C++, to me, is in the following:

(1) Control. There is no limit to how much control I want to have.
(2) Expressiveness; including tools to exercise control safely.

Notice I haven't mentioned the standard library.

*I do not use the standard library.* Some 16 years ago, I found that all
the standard library *actually* does is come between me and the *actual*
platform. Rather than giving me control, it takes away from it. It imposes
this faulty layer of abstraction; with behaviors that can change between
compiler versions; with limitations that turn out to be problematic for
me; with subtle design issues and bugs that I can't work around or fix.

So, *sometimes* I use the standard library. More often than not, though, I
rely on my own containers, which fit usage cases the standard library does
not; including vector and string.

And as much as possible, I work with the underlying platform *directly*.
This has turned out to be a good decision.

With your attempts to "modernize" C++, this is a type of audience you are
alienating. With a medical analogy, the conversation we're having is like
this:

*Surgeon:* I propose this new scalpel, which does these things better than
the old scalpel.
*Committee:* Ah. Well that's good. But it is not good enough. The new
scalpel is unsafe.
*Surgeon:* How is it unsafe?
*Committee:* The scalpel needs to make sure you're not cutting the wrong
thing with it.
*Surgeon:* Isn't it up to the surgeon to be sure what he's cutting?
*Committee:* That's old style thinking. In new surgery, we only want *safe*
tools.
*Surgeon:* But the old scalpel has no such protections either. The old
scalpel is just... a scalpel.
*Committee:* Yes, yes. If we could do it again, we would not have allowed
that.
*Surgeon:* How would we even design a scalpel that knows what it's cutting?
*Committee:* Well, I'm sure someone like you will come along and tell us!

From my perspective - your attempts to build a better standard library are
commendable, and to some extent they are even useful to me, when it
improves the language.

However, I worry that folks are beginning to lose sight of that the C++
standard library is *an* option; not *the only* option.

C++ is more than STL.


On Friday, April 8, 2016 at 12:07:17 AM UTC-6, isocp...@denisbider.com
wrote:

> Ah, Jesus.
>
> It seems to me C++ has become infested with people who call themselves
> "modern", but whose objective is to desperately try to divorce the
> language from its low-level origins, while ashamedly having to recognize
> that this cannot be done, because it would defeat the purpose of the
> language and make it useless for its primary role.
>
> You are now building this over-ambitious standard library monstrosity,
> which is trying to pretend that C++ can be a platform. But the role of C++
> is not to *be* a platform. It is a tool for *building* platforms, and for
> building applications on top of existing platforms.
>
> I can honestly say I don't like what you're doing, and if you keep going
> in this direction, C++ will have to be replaced with something that serves
> its original purpose.
>
> Stop trying to make this a managed language, for god's sake.
>
>
> On Thursday, April 7, 2016 at 11:10:08 PM UTC-6, Sean Middleditch wrote:
>
>> On Thu, Apr 7, 2016 at 9:38 PM,  <isocp...@denisbider.com> wrote:
>> > Hey Sean,
>> >
>> > if you would like to see move destruction / relocation proposed in a
>> safer
>> > form, do you have any ideas about what that safer form would look like?
>>
>> Not with great specifics, or else I'd have written a paper on this. :)
>>
>> I'd imagine it'd have something to do with value categories. The ideal is
>> to ensure that the compiler can statically detect moved-from objects and
>> disable destructor execution and provide diagnostics when the variable is
>> used, unless reinitialized explicitly.
>>
>> >
>> > You refer to that modern C++ discourages direct use of new and delete.
>> Well,
>> > yes, of course. But libraries still need to use new and delete, as well
>> as
>> > placement new, to implement containers. How would you propose
>> implementing
>>
>> They need no such thing. They use allocators. Allocators then need to use
>> placement new (and never delete) in almost all cases, but that is deeply
>> separate from most user code. Very few C++ users have written custom
>> allocators. Or even custom containers.
>>
>> > the standard library without these features?
>>
>> You're forming strawmen. The standard library can be implemented purely
>> with compiler intrinsics for all it matters in this context.
>>
>> >
>> > It is not the intention of this Relocator proposal to be used directly
>> by
>> > end users. The intention is that it would be used in STL
>> implementations, to
>> > solve problems that a lack of destructive move makes difficult.
>>
>> It's a partial solution (it solves a minor efficiency problem for vector
>> and... what else? we've already gone over how it doesn't fix variant) and
>> involves a new form of constructor, new defaulted function rules, and so
>> on. It's a ton of work to add to the standardese and a ton of work to
>> implement for exceedinly little pay-off and leaves us still needing
>> _another_ solution for the other problems that make users (not just a
>> handful of stdlib implementors) clamor for destructive move.
>>
>> It'd be like adding an incomplete version of move semantics that just
>> added a new special syntax for move construction without also adding rvalue
>> references or the extended value categories.
>>
>> Nobody has yet proven that we need to settle for a complicated
>> half-solution. So let's not settle. :)
>>
>> >
>> > Language users should not have to worry about invoking or implementing
>> > relocators, in much the same way they shouldn't have to worry about move
>> > constructors. Language users should use standard library types, and
>> it's up
>> > to the library types to implement relocators and move constructors.
>>
>> In which case, we just need a new type trait and some rules in the
>> standard containers, and _zero_ new language features. Which game engine
>> stdlib replacements have been doing for over a decade. :)
>>
>> >
>> > If you have any ideas of how the proposed feature can be made safer, I
>> would
>> > love to hear about it.
>>
>> My very rough ideas would be to study value categories and rules and find
>> the set of categories that allow for in-place object destruction and
>> marking an object as "expired" so that the compiler knows it doesn't have
>> to invoke destructors. This also ties into lifetimes, and possibly needs to
>> integrate with a more nuanced notion of object lifetime in C++ (and hence
>> possibly should be "bundled" with lifetime extension a la N4221
>> <https://isocpp.org/files/papers/N4221.pdf>)
>>
>> No, that's not a complete idea. I'm not saying I have a magic solution.
>> It may well take _years_ to get any version of this right. If these things
>> were easy or obvious, C++98 would have been a perfect language that never
>> needed another revision ever again. :p
>>
>> >
>> > However, this is not to be mistaken for a feature that end users should
>> > directly use.
>>
>> Then it has no reason to be a heavy-weight feature requiring such
>> extensive compiler support. If it's just for stdlib implementors and stdlib
>> types, they can already offer relocation completely today as a point of QoI
>> via private type traits purely in library code. 100% guarantee it, as I
>> primarily use one that does just that.
>>
>> However, it turns out that "stdlib only" is not actually useful because
>> (a) stdlib containers want to support user-provided types at full
>> functionality, (b) some users do still need to write new containers given
>> how anemic the stdlib is, and (c) relocation as you've proposed doesn't
>> solve any particularly interesting or complicated problems worth the burden
>> it imposes on implementors.
>>
>> You should either make your proposal much simpler pure-library affair or
>> you should think bigger and try to solve a much larger set of the problems
>> that destructive move / relocation could be solving. What you have now is
>> heavy-weight but only solves a very mundane problem.
>>
>> >
>> >
>> > On Wednesday, April 6, 2016 at 10:45:09 PM UTC-6, Sean Middleditch
>> wrote:
>> >>
>> >>
>> >> On Apr 6, 2016 9:55 AM, <isocp...@denisbider.com> wrote:
>> >> >
>> >> > > The committee can mandate that standard library types all have
>> >> > > relocators added where necessary but it can do no such thing for
>> >> > > user types. However, the committee _does_ want to allow variant
>> >> > > to be used with those same problematic user types.
>> >> >
>> >> >
>> >> > With respect to variant, it is already a major advantage of
>> relocation
>> >> > that it can support:
>> >> >
>> >> > - exception-safe use of variant with non-nullable standard library
>> types
>> >> > - without requiring an existing std::list implementation to be
>> thrown away
>> >> > so it can be nothrow_move_constructible;
>> >> >
>> >> > - exception-safe use of variant with future non-nullable types.
>> >>
>> >> But not "exception safe" for other types, meaning that it still
>> requires
>> >> the work around with the valueless state. So we go from a "mostly never
>> >> empty" container to a "slightly more mostly never empty" container. :)
>> >>
>> >> >
>> >> >
>> >> > Existing problematic non-library types can of course still be
>> supported,
>> >> > if we're willing to lose the strong exception safety guarantee in
>> that case.
>> >> > I'm not sure there is a silver bullet that can avoid that.
>> >> >
>> >> >
>> >> > > With your proposal, it's way too easy to accidentally leave
>> >> > > some object in an undefined state
>> >> >
>> >> > I find this logic highly questionable. By this line of reasoning, we
>> >> > should remove placement new, C-style casts, and manual memory
>> management, so
>> >> > that C++ might become a managed language.
>> >>
>> >> Not at all, and that's quite the logical jump. For one, your feature
>> >> doesn't actually exist yet, while those others do; adding unsafe
>> features
>> >> and keeping old unsafe features (that we actually _do_ kinda-sorta
>> >> deprecate, e.g. the modern advice to never ever use new/delete or
>> C-style
>> >> casts) for back-compat are two very different things. :)
>> >>
>> >> For two, there are degrees of ease-of- misuse and not just a binary
>> >> equation of assembly vs C# :)  Rust for instance is a case of going
>> too far
>> >> with protecting users from mistakes and going straight into forcing
>> users to
>> >> jump through hoops to convince the compiler of the validity of
>> perfectly
>> >> valid code. It errs completely on the side of safety. Nobody is
>> (seriously)
>> >> advocating that for C++. Neither should we be advocating to adding more
>> >> C-level-dangerous constructs to C++ without darn good reason.
>> Half-fixing
>> >> variant and not actually fixing many _other_ major problems that
>> destructive
>> >> move could solve (e.g., accidentally using a moved-from parameter
>> instead of
>> >> the moved-to member in a class constructor).
>> >>
>> >> For three, your feature proposal opens whole new classes of mistakes
>> than
>> >> what we have today. The only mechanism even close to being as
>> dangerous is
>> >> delete/free and modern C++ all but deprecates those features in user
>> code,
>> >> even in high-performance situations like AAA games. A "good"
>> destructive
>> >> move should _reduce_ errors in existing code -- like accidentally using
>> >> moved-from values -- rather than adding new ones. Performance alone
>> isn't
>> >> good enough. Remember, rvalue references _real_ goal was to allow us to
>> >> replace things like the easy-to-misuse auto_ptr with the much superior
>> >> unique_ptr. The potential performance improvements of move semantics
>> were
>> >> icing on the cake.
>> >>
>> >> Now let's be clear: the intent of relocation is good. We need someone
>> >> working on this, IMO. I'm more than happy to see you work on it; you
>> seem
>> >> like a pretty bright person and are obviously passionate about the
>> issue. I
>> >> just strongly think that the proposal you currently have just isn't
>> "there"
>> >> yet and needs more design iteration. :)
>> >>
>> >> >
>> >
>> > --
>> > You received this message because you are subscribed to a topic in the
>> > Google Groups "ISO C++ Standard - Future Proposals" group.
>> > To unsubscribe from this topic, visit
>> >
>> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/jdY0hieE0E0/unsubscribe
>> .
>> > To unsubscribe from this group and all its topics, send an email to
>> > std-proposal...@isocpp.org.
>> > To post to this group, send email to std-pr...@isocpp.org.
>> > To view this discussion on the web visit
>> >
>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/4f31b957-05be-47cf-a1ca-03f33a9900c0%40isocpp.org
>> .
>>
>>
>>
>> --
>> Sean Middleditch
>> http://seanmiddleditch.com
>>
>

--
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/5fa18812-ef38-49de-814c-0d062124c4d2%40isocpp.org.

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

<div dir=3D"ltr"><div>Let me expand on this. In doing so, I hope to help yo=
u guys understand the developer audience that, in the name of &quot;moderni=
ty&quot;, you are alienating.</div><div><br></div><div>The key value of C++=
, to me, is in the following:</div><div><br></div><div>(1) Control. There i=
s no limit to how much control I want to have.</div><div>(2) Expressiveness=
; including tools to exercise control safely.</div><div><br></div><div>Noti=
ce I haven&#39;t mentioned the standard library.</div><div><br></div><div><=
em>I do not use the standard library.</em> Some 16 years ago, I found that =
all the standard library <em>actually</em> does is come between me and the =
<em>actual</em> platform. Rather than giving me control, it takes away from=
 it. It imposes this faulty layer of abstraction;=C2=A0with behaviors that =
can change between compiler versions; with limitations that turn out to be =
problematic for me;=C2=A0with subtle=C2=A0design issues and bugs that I can=
&#39;t work around or fix.</div><div><br></div><div>So, <em>sometimes</em> =
I use the standard library. More often than not, though, I rely on my own c=
ontainers, which fit usage cases the standard library does not;=C2=A0includ=
ing vector and string.</div><div><br></div><div>And as=C2=A0much as possibl=
e, I work with the underlying platform <em>directly</em>. This has turned o=
ut to be a good decision.</div><div><br></div><div>With your attempts to &q=
uot;modernize&quot; C++, this is a type of audience you are alienating. Wit=
h a medical analogy, the conversation we&#39;re having is like this:</div><=
div><br></div><div><em>Surgeon:</em> I propose this new scalpel, which does=
 these things better than the old scalpel.</div><div><em>Committee:</em> Ah=
.. Well that&#39;s good. But it is=C2=A0not good enough. The new scalpel is =
unsafe.</div><div><em>Surgeon:</em> How is it unsafe?</div><div><em>Committ=
ee:</em>=C2=A0The scalpel=C2=A0needs to make sure you&#39;re not cutting th=
e wrong thing with it.</div><div><em>Surgeon:</em>=C2=A0Isn&#39;t it=C2=A0u=
p to the surgeon to be sure what he&#39;s cutting?</div><div><em>Committee:=
</em> That&#39;s old style thinking. In new surgery, we only want <strong>s=
afe</strong> tools.</div><div><em>Surgeon:</em> But the old scalpel has no =
such=C2=A0protections either. The old scalpel is just... a scalpel.</div><d=
iv><em>Committee:</em> Yes, yes. If we could do it again, we would not have=
 allowed that.</div><div><em>Surgeon:</em> How would we even design a scalp=
el that knows what it&#39;s cutting?</div><div><div><em>Committee:</em> Wel=
l, I&#39;m sure someone like you will come along and tell us!</div></div><d=
iv><br></div><div>From my perspective - your attempts to build a better sta=
ndard library are commendable, and to some extent they are even useful to m=
e, when it improves the language.</div><div><br></div><div>However, I worry=
 that folks are beginning to=C2=A0lose sight of=C2=A0that the C++ standard =
library is <em>an</em> option; not <em>the only</em>=C2=A0option.</div><div=
><br></div><div>C++ is more than STL.</div><div><br><br>On Friday, April 8,=
 2016 at 12:07:17 AM UTC-6, isocp...@denisbider.com wrote:</div><blockquote=
 class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1e=
x; border-left-color: rgb(204, 204, 204); border-left-width: 1px; border-le=
ft-style: solid;"><div dir=3D"ltr"><div>Ah, Jesus.</div><div><br></div><div=
>It seems to me C++ has become infested with people=C2=A0who call themselve=
s &quot;modern&quot;, but whose=C2=A0objective is to=C2=A0desperately try t=
o divorce=C2=A0the language=C2=A0from its low-level origins, while=C2=A0ash=
amedly having to=C2=A0recognize that this cannot be done, because it would =
defeat the purpose of the language and make it useless for its primary role=
..</div><div><br></div><div>You are now building this over-ambitious standar=
d library monstrosity, which is=C2=A0trying to pretend that C++ can be a pl=
atform. But the=C2=A0role of C++ is not to <em>be</em> a platform. It is a =
tool for <em>building</em> platforms, and for building applications on top =
of existing platforms.</div><div><br></div><div>I can honestly say I don&#3=
9;t like what you&#39;re doing, and if you keep going in this direction, C+=
+ will have to be replaced with something that serves its original purpose.=
</div><div><br></div><div>Stop trying to make this a managed language, for =
god&#39;s sake.</div><div><br><br>On Thursday, April 7, 2016 at 11:10:08 PM=
 UTC-6, Sean Middleditch wrote:</div><blockquote class=3D"gmail_quote" styl=
e=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(2=
04, 204, 204); border-left-width: 1px; border-left-style: solid;"><div dir=
=3D"ltr">On Thu, Apr 7, 2016 at 9:38 PM, =C2=A0&lt;<a rel=3D"nofollow">isoc=
p...@denisbider.com</a>&gt; wrote:<br>&gt; Hey Sean,<br>&gt;<br>&gt; if you=
 would like to see move destruction / relocation proposed in a safer<br>&gt=
; form, do you have any ideas about what that safer form would look like?<b=
r><br>Not with great specifics, or else I&#39;d have written a paper on thi=
s. :)<br><br>I&#39;d imagine it&#39;d have something to do with value categ=
ories. The ideal is to ensure that the compiler can statically detect moved=
-from objects and disable destructor execution and provide diagnostics when=
 the variable is used, unless reinitialized explicitly.<br><br>&gt;<br>&gt;=
 You refer to that modern C++ discourages direct use of new and delete. Wel=
l,<br>&gt; yes, of course. But libraries still need to use new and delete, =
as well as<br>&gt; placement new, to implement containers. How would you pr=
opose implementing<br><br>They need no such thing. They use allocators. All=
ocators then need to use placement new (and never delete) in almost all cas=
es, but that is deeply separate from most user code. Very few C++ users hav=
e written custom allocators. Or even custom containers.<br><br>&gt; the sta=
ndard library without these features?<br><br>You&#39;re forming strawmen. T=
he standard library can be implemented purely with compiler intrinsics for =
all it matters in this context.<br><br>&gt;<br>&gt; It is not the intention=
 of this Relocator proposal to be used directly by<br>&gt; end users. The i=
ntention is that it would be used in STL implementations, to<br>&gt; solve =
problems that a lack of destructive move makes difficult.<br><br>It&#39;s a=
 partial solution (it solves a minor efficiency problem for vector and... w=
hat else? we&#39;ve already gone over how it doesn&#39;t fix variant) and i=
nvolves a new form of constructor, new defaulted function rules, and so on.=
 It&#39;s a ton of work to add to the standardese and a ton of work to impl=
ement for exceedinly little pay-off and leaves us still needing _another_ s=
olution for the other problems that make users (not just a handful of stdli=
b implementors) clamor for destructive move.<br><br>It&#39;d be like adding=
 an incomplete version of move semantics that just added a new special synt=
ax for move construction without also adding rvalue references or the exten=
ded value categories.<br><br>Nobody has yet proven that we need to settle f=
or a complicated half-solution. So let&#39;s not settle. :)<br><br>&gt;<br>=
&gt; Language users should not have to worry about invoking or implementing=
<br>&gt; relocators, in much the same way they shouldn&#39;t have to worry =
about move<br>&gt; constructors. Language users should use standard library=
 types, and it&#39;s up<br>&gt; to the library types to implement relocator=
s and move constructors.<br><br>In which case, we just need a new type trai=
t and some rules in the standard containers, and _zero_ new language featur=
es. Which game engine stdlib replacements have been doing for over a decade=
.. :)<br><br>&gt;<br>&gt; If you have any ideas of how the proposed feature =
can be made safer, I would<br>&gt; love to hear about it.<br><br>My very ro=
ugh ideas would be to study value categories and rules and find the set of =
categories that allow for in-place object destruction and marking an object=
 as &quot;expired&quot; so that the compiler knows it doesn&#39;t have to i=
nvoke destructors. This also ties into lifetimes, and possibly needs to int=
egrate with a more nuanced notion of object lifetime in C++ (and hence poss=
ibly should be &quot;bundled&quot; with lifetime extension a la <a onmoused=
own=3D"this.href=3D&#39;https://www.google.com/url?q\75https%3A%2F%2Fisocpp=
..org%2Ffiles%2Fpapers%2FN4221.pdf\46sa\75D\46sntz\0751\46usg\75AFQjCNEo6r7Y=
vYOoKPOk-oK52v7NQFuPRg&#39;;return true;" onclick=3D"this.href=3D&#39;https=
://www.google.com/url?q\75https%3A%2F%2Fisocpp.org%2Ffiles%2Fpapers%2FN4221=
..pdf\46sa\75D\46sntz\0751\46usg\75AFQjCNEo6r7YvYOoKPOk-oK52v7NQFuPRg&#39;;r=
eturn true;" href=3D"https://isocpp.org/files/papers/N4221.pdf" target=3D"_=
blank" rel=3D"nofollow">N4221</a>)<br><br>No, that&#39;s not a complete ide=
a. I&#39;m not saying I have a magic solution. It may well take _years_ to =
get any version of this right. If these things were easy or obvious, C++98 =
would have been a perfect language that never needed another revision ever =
again. :p<div><br></div><div>&gt;<br>&gt; However, this is not to be mistak=
en for a feature that end users should<br>&gt; directly use.<br><br>Then it=
 has no reason to be a heavy-weight feature requiring such extensive compil=
er support. If it&#39;s just for stdlib implementors and stdlib types, they=
 can already offer relocation completely today as a point of QoI via privat=
e type traits purely in library code. 100% guarantee it, as I primarily use=
 one that does just that.<br><br>However, it turns out that &quot;stdlib on=
ly&quot; is not actually useful because (a) stdlib containers want to suppo=
rt user-provided types at full functionality, (b) some users do still need =
to write new containers given how anemic the stdlib is, and (c) relocation =
as you&#39;ve proposed doesn&#39;t solve any particularly interesting or co=
mplicated problems worth the burden it imposes on implementors.<br><br>You =
should either make your proposal much simpler pure-library affair or you sh=
ould think bigger and try to solve a much larger set of the problems that d=
estructive move / relocation could be solving. What you have now is heavy-w=
eight but only solves a very mundane problem.<br><br>&gt;<br>&gt;<br>&gt; O=
n Wednesday, April 6, 2016 at 10:45:09 PM UTC-6, Sean Middleditch wrote:<br=
>&gt;&gt;<br>&gt;&gt;<br>&gt;&gt; On Apr 6, 2016 9:55 AM, &lt;<a>isocp...@d=
enisbider.com</a>&gt; wrote:<br>&gt;&gt; &gt;<br>&gt;&gt; &gt; &gt; The com=
mittee can mandate that standard library types all have<br>&gt;&gt; &gt; &g=
t; relocators added where necessary but it can do no such thing for<br>&gt;=
&gt; &gt; &gt; user types. However, the committee _does_ want to allow vari=
ant<br>&gt;&gt; &gt; &gt; to be used with those same problematic user types=
..<br>&gt;&gt; &gt;<br>&gt;&gt; &gt;<br>&gt;&gt; &gt; With respect to varian=
t, it is already a major advantage of relocation<br>&gt;&gt; &gt; that it c=
an support:<br>&gt;&gt; &gt;<br>&gt;&gt; &gt; - exception-safe use of varia=
nt with non-nullable standard library types<br>&gt;&gt; &gt; - without requ=
iring an existing std::list implementation to be thrown away<br>&gt;&gt; &g=
t; so it can be nothrow_move_constructible;<br>&gt;&gt; &gt;<br>&gt;&gt; &g=
t; - exception-safe use of variant with future non-nullable types.<br>&gt;&=
gt;<br>&gt;&gt; But not &quot;exception safe&quot; for other types, meaning=
 that it still requires<br>&gt;&gt; the work around with the valueless stat=
e. So we go from a &quot;mostly never<br>&gt;&gt; empty&quot; container to =
a &quot;slightly more mostly never empty&quot; container. :)<br>&gt;&gt;<br=
>&gt;&gt; &gt;<br>&gt;&gt; &gt;<br>&gt;&gt; &gt; Existing problematic non-l=
ibrary types can of course still be supported,<br>&gt;&gt; &gt; if we&#39;r=
e willing to lose the strong exception safety guarantee in that case.<br>&g=
t;&gt; &gt; I&#39;m not sure there is a silver bullet that can avoid that.<=
br>&gt;&gt; &gt;<br>&gt;&gt; &gt;<br>&gt;&gt; &gt; &gt; With your proposal,=
 it&#39;s way too easy to accidentally leave<br>&gt;&gt; &gt; &gt; some obj=
ect in an undefined state<br>&gt;&gt; &gt;<br>&gt;&gt; &gt; I find this log=
ic highly questionable. By this line of reasoning, we<br>&gt;&gt; &gt; shou=
ld remove placement new, C-style casts, and manual memory management, so<br=
>&gt;&gt; &gt; that C++ might become a managed language.<br>&gt;&gt;<br>&gt=
;&gt; Not at all, and that&#39;s quite the logical jump. For one, your feat=
ure<br>&gt;&gt; doesn&#39;t actually exist yet, while those others do; addi=
ng unsafe features<br>&gt;&gt; and keeping old unsafe features (that we act=
ually _do_ kinda-sorta<br>&gt;&gt; deprecate, e.g. the modern advice to nev=
er ever use new/delete or C-style<br>&gt;&gt; casts) for back-compat are tw=
o very different things. :)<br>&gt;&gt;<br>&gt;&gt; For two, there are degr=
ees of ease-of- misuse and not just a binary<br>&gt;&gt; equation of assemb=
ly vs C# :) =C2=A0Rust for instance is a case of going too far<br>&gt;&gt; =
with protecting users from mistakes and going straight into forcing users t=
o<br>&gt;&gt; jump through hoops to convince the compiler of the validity o=
f perfectly<br>&gt;&gt; valid code. It errs completely on the side of safet=
y. Nobody is (seriously)<br>&gt;&gt; advocating that for C++. Neither shoul=
d we be advocating to adding more<br>&gt;&gt; C-level-dangerous constructs =
to C++ without darn good reason. Half-fixing<br>&gt;&gt; variant and not ac=
tually fixing many _other_ major problems that destructive<br>&gt;&gt; move=
 could solve (e.g., accidentally using a moved-from parameter instead of<br=
>&gt;&gt; the moved-to member in a class constructor).<br>&gt;&gt;<br>&gt;&=
gt; For three, your feature proposal opens whole new classes of mistakes th=
an<br>&gt;&gt; what we have today. The only mechanism even close to being a=
s dangerous is<br>&gt;&gt; delete/free and modern C++ all but deprecates th=
ose features in user code,<br>&gt;&gt; even in high-performance situations =
like AAA games. A &quot;good&quot; destructive<br>&gt;&gt; move should _red=
uce_ errors in existing code -- like accidentally using<br>&gt;&gt; moved-f=
rom values -- rather than adding new ones. Performance alone isn&#39;t<br>&=
gt;&gt; good enough. Remember, rvalue references _real_ goal was to allow u=
s to<br>&gt;&gt; replace things like the easy-to-misuse auto_ptr with the m=
uch superior<br>&gt;&gt; unique_ptr. The potential performance improvements=
 of move semantics were<br>&gt;&gt; icing on the cake.<br>&gt;&gt;<br>&gt;&=
gt; Now let&#39;s be clear: the intent of relocation is good. We need someo=
ne<br>&gt;&gt; working on this, IMO. I&#39;m more than happy to see you wor=
k on it; you seem<br>&gt;&gt; like a pretty bright person and are obviously=
 passionate about the issue. I<br>&gt;&gt; just strongly think that the pro=
posal you currently have just isn&#39;t &quot;there&quot;<br>&gt;&gt; yet a=
nd needs more design iteration. :)<br>&gt;&gt;<br>&gt;&gt; &gt;<br>&gt;<br>=
&gt; --<br>&gt; You received this message because you are subscribed to a t=
opic in the<br>&gt; Google Groups &quot;ISO C++ Standard - Future Proposals=
&quot; group.<br>&gt; To unsubscribe from this topic, visit<br>&gt; <a onmo=
usedown=3D"this.href=3D&#39;https://groups.google.com/a/isocpp.org/d/topic/=
std-proposals/jdY0hieE0E0/unsubscribe&#39;;return true;" onclick=3D"this.hr=
ef=3D&#39;https://groups.google.com/a/isocpp.org/d/topic/std-proposals/jdY0=
hieE0E0/unsubscribe&#39;;return true;" href=3D"https://groups.google.com/a/=
isocpp.org/d/topic/std-proposals/jdY0hieE0E0/unsubscribe" target=3D"_blank"=
 rel=3D"nofollow">https://groups.google.com/a/<wbr>isocpp.org/d/topic/std-<=
wbr>proposals/jdY0hieE0E0/<wbr>unsubscribe</a>.<br>&gt; To unsubscribe from=
 this group and all its topics, send an email to<br>&gt; <a rel=3D"nofollow=
">std-proposal...@isocpp.org</a>.<br>&gt; To post to this group, send email=
 to <a rel=3D"nofollow">std-pr...@isocpp.org</a>.<br>&gt; To view this disc=
ussion on the web visit<br>&gt; <a onmousedown=3D"this.href=3D&#39;https://=
groups.google.com/a/isocpp.org/d/msgid/std-proposals/4f31b957-05be-47cf-a1c=
a-03f33a9900c0%40isocpp.org&#39;;return true;" onclick=3D"this.href=3D&#39;=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/4f31b957-05be-=
47cf-a1ca-03f33a9900c0%40isocpp.org&#39;;return true;" href=3D"https://grou=
ps.google.com/a/isocpp.org/d/msgid/std-proposals/4f31b957-05be-47cf-a1ca-03=
f33a9900c0%40isocpp.org" target=3D"_blank" rel=3D"nofollow">https://groups.=
google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/4f31b957-05be-47cf-=
<wbr>a1ca-03f33a9900c0%40isocpp.org</a><wbr>.<br><br><br><br>-- <br>Sean Mi=
ddleditch<br><a onmousedown=3D"this.href=3D&#39;http://www.google.com/url?q=
\75http%3A%2F%2Fseanmiddleditch.com\46sa\75D\46sntz\0751\46usg\75AFQjCNHx3W=
LavT-kbToOv7IL4uvcN5l-vg&#39;;return true;" onclick=3D"this.href=3D&#39;htt=
p://www.google.com/url?q\75http%3A%2F%2Fseanmiddleditch.com\46sa\75D\46sntz=
\0751\46usg\75AFQjCNHx3WLavT-kbToOv7IL4uvcN5l-vg&#39;;return true;" href=3D=
"http://seanmiddleditch.com" target=3D"_blank" rel=3D"nofollow">http://sean=
middleditch.com</a></div></div>
</blockquote></div></blockquote></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/5fa18812-ef38-49de-814c-0d062124c4d2%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/5fa18812-ef38-49de-814c-0d062124c4d2=
%40isocpp.org</a>.<br />

------=_Part_7_518778252.1460099938909--
------=_Part_6_378321275.1460099938908--

.

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

On Fri, Apr 8, 2016 at 12:18 AM, <isocppgroup@denisbider.com> wrote:

> Let me expand on this. In doing so, I hope to help you guys understand the
> developer audience that, in the name of "modernity", you are alienating.
>

> The key value of C++, to me, is in the following:
>
> (1) Control. There is no limit to how much control I want to have.
> (2) Expressiveness; including tools to exercise control safely.
>
>
I think perhaps you should watch my CppCon talk and realize that you're (a)
wildly off-base with your accusation and (b) severely misinterpreting my
points in this thread.

And now you're being belligerent and petulant, so I'm done providing
advice. Good luck on your proposal and have a great night.

--
Sean Middleditch
http://seanmiddleditch.com

--
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/CALQmNFh61w%2BFFStaCpAV7sXdn7JOi6ToWc_tS6kC_3WvaK%3D0CA%40mail.gmail.com.

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On F=
ri, Apr 8, 2016 at 12:18 AM,  <span dir=3D"ltr">&lt;<a href=3D"mailto:isocp=
pgroup@denisbider.com" target=3D"_blank">isocppgroup@denisbider.com</a>&gt;=
</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .=
8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>Let =
me expand on this. In doing so, I hope to help you guys understand the deve=
loper audience that, in the name of &quot;modernity&quot;, you are alienati=
ng.</div></div></blockquote><blockquote class=3D"gmail_quote" style=3D"marg=
in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"=
><div><br></div><div>The key value of C++, to me, is in the following:</div=
><div><br></div><div>(1) Control. There is no limit to how much control I w=
ant to have.</div><div>(2) Expressiveness; including tools to exercise cont=
rol safely.</div><div><br></div></div></blockquote><div><br></div><div>I th=
ink perhaps you should watch my CppCon talk and realize that you&#39;re (a)=
 wildly off-base with your accusation and (b) severely misinterpreting my p=
oints in this thread.</div><div><br></div><div>And now you&#39;re being bel=
ligerent and petulant, so I&#39;m done providing advice. Good luck on your =
proposal and have a great night.</div></div><div><br></div>-- <br><div clas=
s=3D"gmail_signature">Sean Middleditch<br><a href=3D"http://seanmiddleditch=
..com" target=3D"_blank">http://seanmiddleditch.com</a></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/CALQmNFh61w%2BFFStaCpAV7sXdn7JOi6ToWc=
_tS6kC_3WvaK%3D0CA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALQmNFh61w%2=
BFFStaCpAV7sXdn7JOi6ToWc_tS6kC_3WvaK%3D0CA%40mail.gmail.com</a>.<br />

--001a113d1d6cdd2515052ff4397a--

.

------=_Part_719_93571998.1460124722748
Content-Type: multipart/alternative;
 boundary="----=_Part_720_867827720.1460124722748"

------=_Part_720_867827720.1460124722748
Content-Type: text/plain; charset=UTF-8

On Friday, April 8, 2016 at 2:07:17 AM UTC-4, isocp...@denisbider.com wrote:
>
> Ah, Jesus.
>
> It seems to me C++ has become infested with people who call themselves
> "modern", but whose objective is to desperately try to divorce the
> language from its low-level origins, while ashamedly having to recognize
> that this cannot be done, because it would defeat the purpose of the
> language and make it useless for its primary role.
>
> You are now building this over-ambitious standard library monstrosity,
> which is trying to pretend that C++ can be a platform. But the role of C++
> is not to *be* a platform. It is a tool for *building* platforms, and for
> building applications on top of existing platforms.
>
> I can honestly say I don't like what you're doing, and if you keep going
> in this direction, C++ will have to be replaced with something that serves
> its original purpose.
>
> Stop trying to make this a managed language, for god's sake.
>

.... So Sean points out how move support introduced a plethora of new value
categories in order to ensure that it does not get automatically used in
the wrong place. To make sure that it's reasonably safe and usable for most
programmers. And he suggests that you should investigate this sort of thing
as a way to make sure that your "relocation" is also reasonably safe, that
it gets used automatically where appropriate, and that it doesn't get used
in improper places. And so forth.

And your response to this is to claim that such commentary comes from people
<https://en.wikipedia.org/wiki/Ad_hominem> who are "infesting" the
language, that even that we make the language *as safe as it currently is*
represents an attempt to "make this a managed language", and so forth.
You're basically saying that your design is perfect as is, and anyone who
questions it in the name of safety is "desperately try[ing] to divorce the
language from its low-level origins."

Seriously, are you *five-years old*?

And let's not forget the implied insult to the standards committee that
their design for move support is wrong because it actually includes such
safety features.

Personally, my basic criticism of your proposal is that it's not even
really half of a proposal. You can only "relocate" objects who's lifetimes
are governed by `new/delete` or placement new/explicit destructor calls.
That is, not automatic objects. You're basically taking the *easy part* of
destructive move/relocation, and then pretending that you have a complete
"relocation" feature.

If your relocation support can't even perform relocation in this most
simple of cases:

std::list<T> SomeFunc()
{
  std::list<T> lt = ...
  ...
  return lt; //Insert syntax for relocation-returning, if needed
}

Then *what good is it*?

In fact, there is *no way* in your proposal to relocate an object into a
return value. Not even with P0135's guaranteed elision mechanics. Since you
can only relocate an object through the use of `new`, and return values
aren't created by `new`, there is no way to use relocation on simple return
values.

So again, *what good is this?*

That's where the "safety" argument that Sean is making comes from. Your
proposal only works with features that are inherently unsafe and that
programmers increasingly do not use with any particular frequency. Unlike
`move`, which works on *all object*s, automatic and non-automatic alike.

That's the basic point that Sean is (or seems to be) making about your
proposal. You cannot use your proposal without calling upon deep-magic
levels of C++, like placement new and so forth. Your features is brittle,
incomplete, and painful to use.

Allow me to restate your asinine "scalpel" analogy/conversation to better
explain this:

Surgeon: I propose this new scalpel, which does these things better than
> the old scalpel.
> Committee: But it doesn't do things better than the old scalpel. It
> doesn't even work most of the time.
> Surgeon: Sure it does. See, it works just fine if you stand on your head,
> and it does things even better than the old one.
> Committee: But... most people stopped performing surgery while standing on
> their head years ago.
> Surgeon: Isn't it up to the surgeon to decide how he wants to perform
> surgery?
> Committee: That's old style thinking. In modern surgery, we want tools
> that work with how we actually operate on people, not tools that force us
> to operate in a specific way. Especially ones known to be bad.
> Surgeon: But the old scalpel has no such protections either. The old
> scalpel is just... a scalpel.
> Committee: That's not true at all. The old scalpel works just fine when
> standing normally.
> Surgeon: How would we even design a scalpel that does what this does
> without having to stand on your head?
> Committee: Put some effort into it, rather than doing the bare minimum
> that you feel you can get away with. Make a *complete* scalpel.
>

In this analogy, "stand on your head" mean "using new/delete or placement
new and explicit destructor calls".

Indeed, it's not clear to me why it is that your proposal needs to be a
language feature at all. N4034 was able to do what you're talking about
purely as a standard library thing. All it would need to do is say that the
function ends the lifetime of the source object, and that the source object
must not be an automatic object.

You can even have implicitly generated versions which will simply perform a
move from the source to the destination, followed by a destructor call on
the source. It would be deleted for any type `T` who's move constructor is
not `noexcept`.

--
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/d7eee27f-bdfc-45b0-9c29-508dd01975b3%40isocpp.org.

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

<div dir=3D"ltr">On Friday, April 8, 2016 at 2:07:17 AM UTC-4, isocp...@den=
isbider.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"=
ltr"><div>Ah, Jesus.</div><div><br></div><div>It seems to me C++ has become=
 infested with people=C2=A0who call themselves &quot;modern&quot;, but whos=
e=C2=A0objective is to=C2=A0desperately try to divorce=C2=A0the language=C2=
=A0from its low-level origins, while=C2=A0ashamedly having to=C2=A0recogniz=
e that this cannot be done, because it would defeat the purpose of the lang=
uage and make it useless for its primary role.</div><div><br></div><div>You=
 are now building this over-ambitious standard library monstrosity, which i=
s=C2=A0trying to pretend that C++ can be a platform. But the=C2=A0role of C=
++ is not to <i>be</i> a platform. It is a tool for <i>building</i> platfor=
ms, and for building applications on top of existing platforms.</div><div><=
br></div><div>I can honestly say I don&#39;t like what you&#39;re doing, an=
d if you keep going in this direction, C++ will have to be replaced with so=
mething that serves its original purpose.</div><div><br></div><div>Stop try=
ing to make this a managed language, for god&#39;s sake.</div></div></block=
quote><div><br>... So Sean points out how move support introduced a plethor=
a of new value categories in order to ensure that it does not get automatic=
ally used in the wrong place. To make sure that it&#39;s reasonably safe an=
d usable for most programmers. And he suggests that you should investigate =
this sort of thing as a way to make sure that your &quot;relocation&quot; i=
s also reasonably safe, that it gets used automatically where appropriate, =
and that it doesn&#39;t get used in improper places. And so forth.<br><br>A=
nd your response to this is <a href=3D"https://en.wikipedia.org/wiki/Ad_hom=
inem">to claim that such commentary comes from people</a> who are &quot;inf=
esting&quot; the language, that even that we make the language <i>as safe a=
s it currently is</i> represents an attempt to &quot;make this a managed la=
nguage&quot;, and so forth. You&#39;re basically saying that your design is=
 perfect as is, and anyone who questions it in the name of safety is &quot;=
desperately try[ing] to divorce=C2=A0the language=C2=A0from its low-level o=
rigins.&quot;<br><br>Seriously, are you <i>five-years old</i>?<br><br>And l=
et&#39;s not forget the implied insult to the standards committee that thei=
r design for move support is wrong because it actually includes such safety=
 features.<br><br>Personally, my basic criticism of your proposal is that i=
t&#39;s not even really half of a proposal. You can only &quot;relocate&quo=
t; objects who&#39;s lifetimes are governed by `new/delete` or placement ne=
w/explicit destructor calls. That is, not automatic objects. You&#39;re bas=
ically taking the <i>easy part</i> of destructive move/relocation, and then=
 pretending that you have a complete &quot;relocation&quot; feature.<br><br=
>If your relocation support can&#39;t even perform relocation in this most =
simple of cases:<br><br><div class=3D"prettyprint" style=3D"background-colo=
r: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-style: soli=
d; border-width: 1px; word-wrap: break-word;"><code class=3D"prettyprint"><=
div class=3D"subprettyprint"><span style=3D"color: #000;" class=3D"styled-b=
y-prettify">std</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">::</span><span style=3D"color: #000;" class=3D"styled-by-prettify">lis=
t</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify">T</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">&gt;</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #606;" class=3D"styled-by-prettify">SomeFunc</span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">()</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"><br>=C2=A0 std</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">::</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify">list</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">&lt;</span><span style=3D"color: #000;" class=3D"styled-by-prettify">T=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&gt;</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> lt </span><span=
 style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">...</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"><br>=C2=A0 </span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">...</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"><br>=C2=A0 </span><span style=3D"color: #008;" cla=
ss=3D"styled-by-prettify">return</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> lt</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> </span><span style=3D"color: #800;" class=3D"styled-by-prettify">/=
/Insert syntax for relocation-returning, if needed</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">}</span></div></code></div><br>Then <i>wh=
at good is it</i>?<br><br>In fact, there is <i>no way</i> in your proposal =
to relocate an object into a return value. Not even with P0135&#39;s guaran=
teed elision mechanics. Since you can only relocate an object through the u=
se of `new`, and return values aren&#39;t created by `new`, there is no way=
 to use relocation on simple return values.<br><br>So again, <i>what good i=
s this?</i><br><br>That&#39;s where the &quot;safety&quot; argument that Se=
an is making comes from. Your proposal only works with features that are in=
herently unsafe and that programmers increasingly do not use with any parti=
cular frequency. Unlike `move`, which works on <i>all object</i>s, automati=
c and non-automatic alike.<br><br>That&#39;s the basic point that Sean is (=
or seems to be) making about your proposal. You cannot use your proposal wi=
thout calling upon deep-magic levels of C++, like placement new and so fort=
h. Your features is brittle, incomplete, and painful to use.<br><br>Allow m=
e to restate your asinine &quot;scalpel&quot; analogy/conversation to bette=
r explain this:<br><br><blockquote style=3D"margin: 0px 0px 0px 0.8ex; bord=
er-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;" class=3D"gmail_q=
uote">Surgeon: I propose this new scalpel, which does these things better t=
han the old scalpel.<br>Committee: But it doesn&#39;t do things better than=
 the old scalpel. It doesn&#39;t even work most of the time.<br>Surgeon: Su=
re it does. See, it works just fine if you stand on your head, and it does =
things even better than the old one.<br>Committee: But... most people stopp=
ed performing surgery while standing on their head years ago.<br>Surgeon: I=
sn&#39;t it up to the surgeon to decide how he wants to perform surgery?<br=
>Committee: That&#39;s old style thinking. In modern surgery, we want tools=
 that work with how we actually operate on people, not tools that force us =
to operate in a specific way. Especially ones known to be bad.<br>Surgeon: =
But the old scalpel has no such protections either. The old scalpel is just=
.... a scalpel.<br>Committee: That&#39;s not true at all. The old scalpel wo=
rks just fine when standing normally.<br>Surgeon: How would we even design =
a scalpel that does what this does without having to stand on your head?<br=
>Committee: Put some effort into it, rather than doing the bare minimum tha=
t you feel you can get away with. Make a <i>complete</i> scalpel.<br></bloc=
kquote><div><br>In this analogy, &quot;stand on your head&quot; mean &quot;=
using new/delete or placement new and explicit destructor calls&quot;.<br><=
br>Indeed, it&#39;s not clear to me why it is that your proposal needs to b=
e a=20
language feature at all. N4034 was able to do what you&#39;re talking about=
=20
purely as a standard library thing. All it would need to do is say that=20
the function ends the lifetime of the source object, and that the source
 object must not be an automatic object.<br><br>You can even have implicitl=
y generated versions which will simply perform a move from the source to th=
e destination, followed by a destructor call on the source. It would be del=
eted for any type `T` who&#39;s move constructor is not `noexcept`.<br></di=
v></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/d7eee27f-bdfc-45b0-9c29-508dd01975b3%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/d7eee27f-bdfc-45b0-9c29-508dd01975b3=
%40isocpp.org</a>.<br />

------=_Part_720_867827720.1460124722748--
------=_Part_719_93571998.1460124722748--

.

------=_Part_1046_1148487956.1460141502506
Content-Type: multipart/alternative;
 boundary="----=_Part_1047_829198281.1460141502508"

------=_Part_1047_829198281.1460141502508
Content-Type: text/plain; charset=UTF-8



On Friday, April 8, 2016 at 4:12:03 PM UTC+2, Nicol Bolas wrote:
>
> On Friday, April 8, 2016 at 2:07:17 AM UTC-4, isocp...@denisbider.com
> wrote:
>>
>> Ah, Jesus.
>>
>> It seems to me C++ has become infested with people who call themselves
>> "modern", but whose objective is to desperately try to divorce the
>> language from its low-level origins, while ashamedly having to recognize
>> that this cannot be done, because it would defeat the purpose of the
>> language and make it useless for its primary role.
>>
>> You are now building this over-ambitious standard library monstrosity,
>> which is trying to pretend that C++ can be a platform. But the role of C++
>> is not to *be* a platform. It is a tool for *building* platforms, and
>> for building applications on top of existing platforms.
>>
>> I can honestly say I don't like what you're doing, and if you keep going
>> in this direction, C++ will have to be replaced with something that serves
>> its original purpose.
>>
>> Stop trying to make this a managed language, for god's sake.
>>
>
> ... So Sean points out how move support introduced a plethora of new value
> categories in order to ensure that it does not get automatically used in
> the wrong place. To make sure that it's reasonably safe and usable for most
> programmers. And he suggests that you should investigate this sort of thing
> as a way to make sure that your "relocation" is also reasonably safe, that
> it gets used automatically where appropriate, and that it doesn't get used
> in improper places. And so forth.
>
> And your response to this is to claim that such commentary comes from
> people <https://en.wikipedia.org/wiki/Ad_hominem> who are "infesting" the
> language, that even that we make the language *as safe as it currently is*
> represents an attempt to "make this a managed language", and so forth.
> You're basically saying that your design is perfect as is, and anyone who
> questions it in the name of safety is "desperately try[ing] to divorce the
> language from its low-level origins."
>
> Seriously, are you *five-years old*?
>
> And let's not forget the implied insult to the standards committee that
> their design for move support is wrong because it actually includes such
> safety features.
>
> Personally, my basic criticism of your proposal is that it's not even
> really half of a proposal. You can only "relocate" objects who's lifetimes
> are governed by `new/delete` or placement new/explicit destructor calls.
> That is, not automatic objects. You're basically taking the *easy part*
> of destructive move/relocation, and then pretending that you have a
> complete "relocation" feature.
>
> If your relocation support can't even perform relocation in this most
> simple of cases:
>
> std::list<T> SomeFunc()
> {
>   std::list<T> lt = ...
>   ...
>   return lt; //Insert syntax for relocation-returning, if needed
> }
>
> Then *what good is it*?
>
> In fact, there is *no way* in your proposal to relocate an object into a
> return value. Not even with P0135's guaranteed elision mechanics. Since you
> can only relocate an object through the use of `new`, and return values
> aren't created by `new`, there is no way to use relocation on simple return
> values.
>
> So again, *what good is this?*
>
> That's where the "safety" argument that Sean is making comes from. Your
> proposal only works with features that are inherently unsafe and that
> programmers increasingly do not use with any particular frequency. Unlike
> `move`, which works on *all object*s, automatic and non-automatic alike.
>
> That's the basic point that Sean is (or seems to be) making about your
> proposal. You cannot use your proposal without calling upon deep-magic
> levels of C++, like placement new and so forth. Your features is brittle,
> incomplete, and painful to use.
>
> Allow me to restate your asinine "scalpel" analogy/conversation to better
> explain this:
>
> Surgeon: I propose this new scalpel, which does these things better than
>> the old scalpel.
>> Committee: But it doesn't do things better than the old scalpel. It
>> doesn't even work most of the time.
>> Surgeon: Sure it does. See, it works just fine if you stand on your head,
>> and it does things even better than the old one.
>> Committee: But... most people stopped performing surgery while standing
>> on their head years ago.
>> Surgeon: Isn't it up to the surgeon to decide how he wants to perform
>> surgery?
>> Committee: That's old style thinking. In modern surgery, we want tools
>> that work with how we actually operate on people, not tools that force us
>> to operate in a specific way. Especially ones known to be bad.
>> Surgeon: But the old scalpel has no such protections either. The old
>> scalpel is just... a scalpel.
>> Committee: That's not true at all. The old scalpel works just fine when
>> standing normally.
>> Surgeon: How would we even design a scalpel that does what this does
>> without having to stand on your head?
>> Committee: Put some effort into it, rather than doing the bare minimum
>> that you feel you can get away with. Make a *complete* scalpel.
>>
>
> In this analogy, "stand on your head" mean "using new/delete or placement
> new and explicit destructor calls".
>
> Indeed, it's not clear to me why it is that your proposal needs to be a
> language feature at all. N4034 was able to do what you're talking about
> purely as a standard library thing. All it would need to do is say that the
> function ends the lifetime of the source object, and that the source object
> must not be an automatic object.
>
> You can even have implicitly generated versions which will simply perform
> a move from the source to the destination, followed by a destructor call on
> the source. It would be deleted for any type `T` who's move constructor is
> not `noexcept`.
>

 I think biggest problem is trying to shoehorn destructive move to object
with custom destructor. We already have types that have "destructive move",
there are PODs. They need wrapper that manage lifetime of data from
internal object. Great example of this is `unique_ptr` that manage raw
pointer. We could even expand this to `unique_vector` that will manage
array of unique pointers. Extracting one pointer from it will only need one
`memmove` operation, inserting new will need only this too.

I think that is possible to create today library that will handle that kind
of types:

struct pod
{
    int x, y;
    friend void init(pod*); //pseudo constructor
    friend void destroy(pod*); //pseudo destructor
    friend void move(pod*, pod*); //pseudo copy constructor, if not find
library use memcopy
};

template<typename P>
class Warper
{
    static_assert(std::is_pod<P>(), "Type need to be POD");
    P p;
public:
    Warper() : p{} { init(&p); }
    ~Warper() { destroy(&p); }
};
template<typename> class Warper_vector;
template<typename P>
class Warper_movable
{
    static_assert(std::is_pod<P>(), "Type need to be POD");
    friend class Warper_vector<P>;
    bool empty;
    P p;
public:
    Warper_movable() : empty{false}, p{} { init(&p); }
    Warper_movable(Warper_movable&& r) : empty{false}, p{} { move(&r.p, &p);
r.empty = true; }
    ~Warper_movable() { if (!empty) destroy(&p); }
};
template<typename P>
class Warper_vector
{
    static_assert(std::is_pod<P>(), "Type need to be POD");
    std::vector<P> v;
public:
    Warper_vector() : v(10) { for (auto& p : v) init(&p); }
    ~Warper_vector() { for (auto& p : v) destroy(&p); }

    void push_back(Warper_movable<P>&& r)
    {
        v.push_back(r.p); //no destructors or constructors calls
        r.empty = true; //we can now optimalzie out `Warper_movable` call
to `destroy`.
    }
};

int main()
{
    Warper_vector<pod> vec;
    for (int i = 0; i < 10; ++i)
    {
        Warper_movable<pod> obj;
        vec.push_back(std::move(obj));
    }
} //`init` and `destroy` is call 20 times





--
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/42c08c4f-dae2-4705-922b-a1ddf8ca7839%40isocpp.org.

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

<div dir=3D"ltr"><br><br>On Friday, April 8, 2016 at 4:12:03 PM UTC+2, Nico=
l Bolas wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"=
>On Friday, April 8, 2016 at 2:07:17 AM UTC-4, <a>isocp...@denisbider.com</=
a> 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"><div>Ah, =
Jesus.</div><div><br></div><div>It seems to me C++ has become infested with=
 people=C2=A0who call themselves &quot;modern&quot;, but whose=C2=A0objecti=
ve is to=C2=A0desperately try to divorce=C2=A0the language=C2=A0from its lo=
w-level origins, while=C2=A0ashamedly having to=C2=A0recognize that this ca=
nnot be done, because it would defeat the purpose of the language and make =
it useless for its primary role.</div><div><br></div><div>You are now build=
ing this over-ambitious standard library monstrosity, which is=C2=A0trying =
to pretend that C++ can be a platform. But the=C2=A0role of C++ is not to <=
i>be</i> a platform. It is a tool for <i>building</i> platforms, and for bu=
ilding applications on top of existing platforms.</div><div><br></div><div>=
I can honestly say I don&#39;t like what you&#39;re doing, and if you keep =
going in this direction, C++ will have to be replaced with something that s=
erves its original purpose.</div><div><br></div><div>Stop trying to make th=
is a managed language, for god&#39;s sake.</div></div></blockquote><div><br=
>... So Sean points out how move support introduced a plethora of new value=
 categories in order to ensure that it does not get automatically used in t=
he wrong place. To make sure that it&#39;s reasonably safe and usable for m=
ost programmers. And he suggests that you should investigate this sort of t=
hing as a way to make sure that your &quot;relocation&quot; is also reasona=
bly safe, that it gets used automatically where appropriate, and that it do=
esn&#39;t get used in improper places. And so forth.<br><br>And your respon=
se to this is <a href=3D"https://en.wikipedia.org/wiki/Ad_hominem" target=
=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;https://www.go=
ogle.com/url?q\75https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FAd_hominem\46sa\75=
D\46sntz\0751\46usg\75AFQjCNG-BwifY9ygNjAtJUGk8AHKdjZJiQ&#39;;return true;"=
 onclick=3D"this.href=3D&#39;https://www.google.com/url?q\75https%3A%2F%2Fe=
n.wikipedia.org%2Fwiki%2FAd_hominem\46sa\75D\46sntz\0751\46usg\75AFQjCNG-Bw=
ifY9ygNjAtJUGk8AHKdjZJiQ&#39;;return true;">to claim that such commentary c=
omes from people</a> who are &quot;infesting&quot; the language, that even =
that we make the language <i>as safe as it currently is</i> represents an a=
ttempt to &quot;make this a managed language&quot;, and so forth. You&#39;r=
e basically saying that your design is perfect as is, and anyone who questi=
ons it in the name of safety is &quot;desperately try[ing] to divorce=C2=A0=
the language=C2=A0from its low-level origins.&quot;<br><br>Seriously, are y=
ou <i>five-years old</i>?<br><br>And let&#39;s not forget the implied insul=
t to the standards committee that their design for move support is wrong be=
cause it actually includes such safety features.<br><br>Personally, my basi=
c criticism of your proposal is that it&#39;s not even really half of a pro=
posal. You can only &quot;relocate&quot; objects who&#39;s lifetimes are go=
verned by `new/delete` or placement new/explicit destructor calls. That is,=
 not automatic objects. You&#39;re basically taking the <i>easy part</i> of=
 destructive move/relocation, and then pretending that you have a complete =
&quot;relocation&quot; feature.<br><br>If your relocation support can&#39;t=
 even perform relocation in this most simple of cases:<br><br><div style=3D=
"background-color:rgb(250,250,250);border-color:rgb(187,187,187);border-sty=
le:solid;border-width:1px;word-wrap:break-word"><code><div><span style=3D"c=
olor:#000">std</span><span style=3D"color:#660">::</span><span style=3D"col=
or:#000">list</span><span style=3D"color:#660">&lt;</span><span style=3D"co=
lor:#000">T</span><span style=3D"color:#660">&gt;</span><span style=3D"colo=
r:#000"> </span><span style=3D"color:#606">SomeFunc</span><span style=3D"co=
lor:#660">()</span><span style=3D"color:#000"><br></span><span style=3D"col=
or:#660">{</span><span style=3D"color:#000"><br>=C2=A0 std</span><span styl=
e=3D"color:#660">::</span><span style=3D"color:#000">list</span><span style=
=3D"color:#660">&lt;</span><span style=3D"color:#000">T</span><span style=
=3D"color:#660">&gt;</span><span style=3D"color:#000"> lt </span><span styl=
e=3D"color:#660">=3D</span><span style=3D"color:#000"> </span><span style=
=3D"color:#660">...</span><span style=3D"color:#000"><br>=C2=A0 </span><spa=
n style=3D"color:#660">...</span><span style=3D"color:#000"><br>=C2=A0 </sp=
an><span style=3D"color:#008">return</span><span style=3D"color:#000"> lt</=
span><span style=3D"color:#660">;</span><span style=3D"color:#000"> </span>=
<span style=3D"color:#800">//Insert syntax for relocation-returning, if nee=
ded</span><span style=3D"color:#000"><br></span><span style=3D"color:#660">=
}</span></div></code></div><br>Then <i>what good is it</i>?<br><br>In fact,=
 there is <i>no way</i> in your proposal to relocate an object into a retur=
n value. Not even with P0135&#39;s guaranteed elision mechanics. Since you =
can only relocate an object through the use of `new`, and return values are=
n&#39;t created by `new`, there is no way to use relocation on simple retur=
n values.<br><br>So again, <i>what good is this?</i><br><br>That&#39;s wher=
e the &quot;safety&quot; argument that Sean is making comes from. Your prop=
osal only works with features that are inherently unsafe and that programme=
rs increasingly do not use with any particular frequency. Unlike `move`, wh=
ich works on <i>all object</i>s, automatic and non-automatic alike.<br><br>=
That&#39;s the basic point that Sean is (or seems to be) making about your =
proposal. You cannot use your proposal without calling upon deep-magic leve=
ls of C++, like placement new and so forth. Your features is brittle, incom=
plete, and painful to use.<br><br>Allow me to restate your asinine &quot;sc=
alpel&quot; analogy/conversation to better explain this:<br><br><blockquote=
 style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);p=
adding-left:1ex" class=3D"gmail_quote">Surgeon: I propose this new scalpel,=
 which does these things better than the old scalpel.<br>Committee: But it =
doesn&#39;t do things better than the old scalpel. It doesn&#39;t even work=
 most of the time.<br>Surgeon: Sure it does. See, it works just fine if you=
 stand on your head, and it does things even better than the old one.<br>Co=
mmittee: But... most people stopped performing surgery while standing on th=
eir head years ago.<br>Surgeon: Isn&#39;t it up to the surgeon to decide ho=
w he wants to perform surgery?<br>Committee: That&#39;s old style thinking.=
 In modern surgery, we want tools that work with how we actually operate on=
 people, not tools that force us to operate in a specific way. Especially o=
nes known to be bad.<br>Surgeon: But the old scalpel has no such protection=
s either. The old scalpel is just... a scalpel.<br>Committee: That&#39;s no=
t true at all. The old scalpel works just fine when standing normally.<br>S=
urgeon: How would we even design a scalpel that does what this does without=
 having to stand on your head?<br>Committee: Put some effort into it, rathe=
r than doing the bare minimum that you feel you can get away with. Make a <=
i>complete</i> scalpel.<br></blockquote><div><br>In this analogy, &quot;sta=
nd on your head&quot; mean &quot;using new/delete or placement new and expl=
icit destructor calls&quot;.<br><br>Indeed, it&#39;s not clear to me why it=
 is that your proposal needs to be a=20
language feature at all. N4034 was able to do what you&#39;re talking about=
=20
purely as a standard library thing. All it would need to do is say that=20
the function ends the lifetime of the source object, and that the source
 object must not be an automatic object.<br><br>You can even have implicitl=
y generated versions which will simply perform a move from the source to th=
e destination, followed by a destructor call on the source. It would be del=
eted for any type `T` who&#39;s move constructor is not `noexcept`.<br></di=
v></div></div></blockquote><div>=C2=A0</div><div>=C2=A0I think biggest prob=
lem is trying to <span data-dobid=3D"hdw">shoehorn destructive move to obje=
ct with custom destructor. We already have types that have &quot;destructiv=
e move&quot;, there are PODs. They need wrapper that manage lifetime of dat=
a from internal object. Great example of this is `unique_ptr` that manage r=
aw pointer. We could even expand this to `unique_vector` that will manage a=
rray of unique pointers. Extracting one pointer from it will only need one =
`memmove` operation, inserting new will need only this too.<br><br>I think =
that is possible to create today library that will handle that kind of type=
s:<br><br><div class=3D"prettyprint" style=3D"background-color: rgb(250, 25=
0, 250); border-color: rgb(187, 187, 187); border-style: solid; border-widt=
h: 1px; word-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"s=
ubprettyprint"><span style=3D"color: #008;" class=3D"styled-by-prettify">st=
ruct</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> pod<b=
r></span><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0=
 </span><span style=3D"color: #008;" class=3D"styled-by-prettify">int</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> x</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> y</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 </span><span style=3D"color: #00=
8;" class=3D"styled-by-prettify">friend</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"=
styled-by-prettify">void</span><span style=3D"color: #000;" class=3D"styled=
-by-prettify"> init</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
pod</span><span style=3D"color: #660;" class=3D"styled-by-prettify">*);</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span =
style=3D"color: #800;" class=3D"styled-by-prettify">//pseudo constructor</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =
=C2=A0 </span><span style=3D"color: #008;" class=3D"styled-by-prettify">fri=
end</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span=
><span style=3D"color: #008;" class=3D"styled-by-prettify">void</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify"> destroy</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify">pod</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">*);</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"> </span><span style=3D"color: #800;" class=3D"s=
tyled-by-prettify">//pseudo destructor</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 </span><span style=3D"color: =
#008;" class=3D"styled-by-prettify">friend</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">void</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> move</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy">pod</span><span style=3D"color: #660;" class=3D"styled-by-prettify">*,<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> pod</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">*);</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"c=
olor: #800;" class=3D"styled-by-prettify">//pseudo copy constructor, if not=
 find library use memcopy</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"><br></span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">};</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
><br><br></span><span style=3D"color: #008;" class=3D"styled-by-prettify">t=
emplate</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&lt=
;</span><span style=3D"color: #008;" class=3D"styled-by-prettify">typename<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> P</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">&gt;</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D=
"color: #008;" class=3D"styled-by-prettify">class</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #606;"=
 class=3D"styled-by-prettify">Warper</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">{</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"><br>=C2=A0 =C2=A0 </span><span style=3D"color: #008;" class=3D"s=
tyled-by-prettify">static_assert</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify">std</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">::</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
is_pod</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&lt;=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify">P</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">&gt;(),</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D=
"color: #080;" class=3D"styled-by-prettify">&quot;Type need to be POD&quot;=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">);</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 =
P p</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span=
 style=3D"color: #008;" class=3D"styled-by-prettify">public</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">:</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 </span><span styl=
e=3D"color: #606;" class=3D"styled-by-prettify">Warper</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: #660;" cl=
ass=3D"styled-by-prettify">:</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> p</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: #660;" class=3D"styled-by-prettify">{</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> init</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">(&amp;</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify">p</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">);</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">}</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"><br>=C2=A0 =C2=A0 </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">~</span><span style=3D"color: #606;" class=3D"style=
d-by-prettify">Warper</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">()</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">{</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"> destroy</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">(&amp;</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify">p</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">);</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;"=
 class=3D"styled-by-prettify">}</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"><br></span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">};</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"><br></span><span style=3D"color: #008;" class=3D"styled-by-prettify"=
>template</span><span style=3D"color: #080;" class=3D"styled-by-prettify">&=
lt;typename&gt;</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">clas=
s</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><=
span style=3D"color: #606;" class=3D"styled-by-prettify">Warper_vector</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">template</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"co=
lor: #008;" class=3D"styled-by-prettify">typename</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"> P</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">&gt;</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"><br></span><span style=3D"color: #008;" class=3D"s=
tyled-by-prettify">class</span><span style=3D"color: #000;" class=3D"styled=
-by-prettify"> </span><span style=3D"color: #606;" class=3D"styled-by-prett=
ify">Warper_movable</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"><br></span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">{</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=
=C2=A0 =C2=A0 </span><span style=3D"color: #008;" class=3D"styled-by-pretti=
fy">static_assert</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">st=
d</span><span style=3D"color: #660;" class=3D"styled-by-prettify">::</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify">is_pod</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify">P</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">&gt;(),</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #080;" cl=
ass=3D"styled-by-prettify">&quot;Type need to be POD&quot;</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">);</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 </span><span styl=
e=3D"color: #008;" class=3D"styled-by-prettify">friend</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #=
008;" class=3D"styled-by-prettify">class</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify"> </span><span style=3D"color: #606;" class=3D=
"styled-by-prettify">Warper_vector</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">&lt;</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify">P</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">&gt;;</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"><br>=C2=A0 =C2=A0 </span><span style=3D"color: #008;" class=3D"styled-b=
y-prettify">bool</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> empty</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=
=A0 =C2=A0 P p</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br><=
/span><span style=3D"color: #008;" class=3D"styled-by-prettify">public</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">:</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 </span=
><span style=3D"color: #606;" class=3D"styled-by-prettify">Warper_movable</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">()</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">:</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> empty</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">{</span><span style=3D"color: #008;" clas=
s=3D"styled-by-prettify">false</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">},</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> p</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">{}</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify"> init</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">(&amp;</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify">p</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">);</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">}</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"><br>=C2=A0 =C2=A0 </span><span style=3D"color: #606;" class=3D"sty=
led-by-prettify">Warper_movable</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">(</span><span style=3D"color: #606;" class=3D"styled-b=
y-prettify">Warper_movable</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">&amp;&amp;</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"> r</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">)</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">:</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> empty</span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"=
color: #008;" class=3D"styled-by-prettify">false</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">},</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify"> p</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">{}</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">{</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> m=
ove</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(&amp;<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify">r</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">.</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">p</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: #660;" class=3D"=
styled-by-prettify">&amp;</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify">p</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">);</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> r=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">.</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify">empty </span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #008;" class=3D"styled-by-prettify">true</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: #660;" class=3D"style=
d-by-prettify">}</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"><br>=C2=A0 =C2=A0 </span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">~</span><span style=3D"color: #606;" class=3D"styled-by-prett=
ify">Warper_movable</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">()</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span sty=
le=3D"color: #008;" class=3D"styled-by-prettify">if</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">(!</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">empty</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">)</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> destroy</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">(&amp;</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy">p</span><span style=3D"color: #660;" class=3D"styled-by-prettify">);</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span=
 style=3D"color: #660;" class=3D"styled-by-prettify">}</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">};</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify"><br></span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">template</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">&lt;</span><span style=3D"color: #008;" class=3D"st=
yled-by-prettify">typename</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"> P</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">&gt;</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"><br></span><span style=3D"color: #008;" class=3D"styled-by-prettify">clas=
s</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><=
span style=3D"color: #606;" class=3D"styled-by-prettify">Warper_vector</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 </span><sp=
an style=3D"color: #008;" class=3D"styled-by-prettify">static_assert</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify">std</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">::</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify">is_pod</span><span style=3D"color: #660;"=
 class=3D"styled-by-prettify">&lt;</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">P</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">&gt;(),</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> </span><span style=3D"color: #080;" class=3D"styled-by-prettif=
y">&quot;Type need to be POD&quot;</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">);</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"><br>=C2=A0 =C2=A0 std</span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">::</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify">vector</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">&lt;</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify">P</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
&gt;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> v</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">public</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">:</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 </span><span style=3D"c=
olor: #606;" class=3D"styled-by-prettify">Warper_vector</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">()</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;"=
 class=3D"styled-by-prettify">:</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> v</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">(</span><span style=3D"color: #066;" class=3D"styled-by-pretti=
fy">10</span><span style=3D"color: #660;" class=3D"styled-by-prettify">)</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> </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: #=
008;" class=3D"styled-by-prettify">for</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">(</span><span style=3D"color: #008;" class=3D"styled-by-=
prettify">auto</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">&amp;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
p </span><span style=3D"color: #660;" class=3D"styled-by-prettify">:</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"> v</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">)</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> init</span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">(&amp;</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify">p</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">);</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">}</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><b=
r>=C2=A0 =C2=A0 </span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">~</span><span style=3D"color: #606;" class=3D"styled-by-prettify">War=
per_vector</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: #660;" class=3D"styled-by-prettify">{</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"col=
or: #008;" class=3D"styled-by-prettify">for</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">(</span><span style=3D"color: #008;" class=3D"style=
d-by-prettify">auto</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">&amp;</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> p </span><span style=3D"color: #660;" class=3D"styled-by-prettify">:</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> v</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">)</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> destroy</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">(&amp;</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify">p</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">);</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">}</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"><br><br>=C2=A0 =C2=A0 </span><span style=3D"color: #008;" class=3D"=
styled-by-prettify">void</span><span style=3D"color: #000;" class=3D"styled=
-by-prettify"> push_back</span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">(</span><span style=3D"color: #606;" class=3D"styled-by-prett=
ify">Warper_movable</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">&lt;</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y">P</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&gt;&a=
mp;&amp;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> r=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">)</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 <=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 =
=C2=A0 =C2=A0 v</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">.</span><span style=3D"color: #000;" class=3D"styled-by-prettify">push=
_back</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify">r</span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">.</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify">p</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">);</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> </span><span style=3D"color: #800;" class=3D"sty=
led-by-prettify">//no destructors or constructors calls</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 r</span><span style=3D"color: #660;" class=3D"styled-by-prettify">.</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify">empty </span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"co=
lor: #008;" class=3D"styled-by-prettify">true</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> </span><span style=3D"color: #800;" class=3D"sty=
led-by-prettify">//we can now optimalzie out `Warper_movable` call to `dest=
roy`.</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=
=C2=A0 =C2=A0 </span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">}</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br><=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">};</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"><br><br></span><spa=
n style=3D"color: #008;" class=3D"styled-by-prettify">int</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> main</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">()</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"><br>=C2=A0 =C2=A0 </span><span style=3D"color: #606;" cl=
ass=3D"styled-by-prettify">Warper_vector</span><span style=3D"color: #080;"=
 class=3D"styled-by-prettify">&lt;pod&gt;</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"> vec</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"><br>=C2=A0 =C2=A0 </span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">for</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">(</span><span style=3D"color: #008;" class=3D"styled-by-prettify">i=
nt</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> i </spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D=
"color: #066;" class=3D"styled-by-prettify">0</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> i </span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">&lt;</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"> </span><span style=3D"color: #066;" class=3D"styled-by-pretti=
fy">10</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span=
 style=3D"color: #660;" class=3D"styled-by-prettify">++</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">i</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">)</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 </span><span style=3D"color:=
 #660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span st=
yle=3D"color: #606;" class=3D"styled-by-prettify">Warper_movable</span><spa=
n style=3D"color: #080;" class=3D"styled-by-prettify">&lt;pod&gt;</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> obj</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 vec=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">.</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify">push_back</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">std</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">::</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify">move</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify">obj</span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">));</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"><br>=C2=A0 =C2=A0 </span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">}</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"><br></span><span style=3D"color: #660;" class=3D"styled-by-prettify">}</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span=
 style=3D"color: #800;" class=3D"styled-by-prettify">//`init` and `destroy`=
 is call 20 times</span></div></code></div><br><br><br><br><br></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/42c08c4f-dae2-4705-922b-a1ddf8ca7839%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/42c08c4f-dae2-4705-922b-a1ddf8ca7839=
%40isocpp.org</a>.<br />

------=_Part_1047_829198281.1460141502508--
------=_Part_1046_1148487956.1460141502506--

.

------=_Part_954_388927962.1460147137852
Content-Type: multipart/alternative;
 boundary="----=_Part_955_1309426839.1460147137853"

------=_Part_955_1309426839.1460147137853
Content-Type: text/plain; charset=UTF-8

Nicol - the content of your response is no less ego-based than you claim
mine is. You are deeply annoyed both by me as a person, and by what I am
trying to do.

As far as I can tell, this annoyance seems to be based on
misunderstandings. Perhaps like this:


> If your relocation support can't even perform relocation in this most
simple of cases:

How does it *not* handle that case? If std::list has a relocator, the
compiler can just call the relocator in this case:

  std::list<T> SomeFunc() {
    std::list<T> lt = ...
    ...
    return lt; // no special syntax needed; compiler calls relocator >>list<T>
  }


What prevents the compiler from doing this?



On Friday, April 8, 2016 at 8:12:03 AM UTC-6, Nicol Bolas wrote:

> On Friday, April 8, 2016 at 2:07:17 AM UTC-4, isocp...@denisbider.com
> wrote:
>>
>> Ah, Jesus.
>>
>> It seems to me C++ has become infested with people who call themselves
>> "modern", but whose objective is to desperately try to divorce the
>> language from its low-level origins, while ashamedly having to recognize
>> that this cannot be done, because it would defeat the purpose of the
>> language and make it useless for its primary role.
>>
>> You are now building this over-ambitious standard library monstrosity,
>> which is trying to pretend that C++ can be a platform. But the role of C++
>> is not to *be* a platform. It is a tool for *building* platforms, and
>> for building applications on top of existing platforms.
>>
>> I can honestly say I don't like what you're doing, and if you keep going
>> in this direction, C++ will have to be replaced with something that serves
>> its original purpose.
>>
>> Stop trying to make this a managed language, for god's sake.
>>
>
> ... So Sean points out how move support introduced a plethora of new value
> categories in order to ensure that it does not get automatically used in
> the wrong place. To make sure that it's reasonably safe and usable for most
> programmers. And he suggests that you should investigate this sort of thing
> as a way to make sure that your "relocation" is also reasonably safe, that
> it gets used automatically where appropriate, and that it doesn't get used
> in improper places. And so forth.
>
> And your response to this is to claim that such commentary comes from
> people <https://en.wikipedia.org/wiki/Ad_hominem> who are "infesting" the
> language, that even that we make the language *as safe as it currently is*
> represents an attempt to "make this a managed language", and so forth.
> You're basically saying that your design is perfect as is, and anyone who
> questions it in the name of safety is "desperately try[ing] to divorce the
> language from its low-level origins."
>
> Seriously, are you *five-years old*?
>
> And let's not forget the implied insult to the standards committee that
> their design for move support is wrong because it actually includes such
> safety features.
>
> Personally, my basic criticism of your proposal is that it's not even
> really half of a proposal. You can only "relocate" objects who's lifetimes
> are governed by `new/delete` or placement new/explicit destructor calls.
> That is, not automatic objects. You're basically taking the *easy part*
> of destructive move/relocation, and then pretending that you have a
> complete "relocation" feature.
>
> If your relocation support can't even perform relocation in this most
> simple of cases:
>
> std::list<T> SomeFunc()
> {
>   std::list<T> lt = ...
>   ...
>   return lt; //Insert syntax for relocation-returning, if needed
> }
>
> Then *what good is it*?
>
> In fact, there is *no way* in your proposal to relocate an object into a
> return value. Not even with P0135's guaranteed elision mechanics. Since you
> can only relocate an object through the use of `new`, and return values
> aren't created by `new`, there is no way to use relocation on simple return
> values.
>
> So again, *what good is this?*
>
> That's where the "safety" argument that Sean is making comes from. Your
> proposal only works with features that are inherently unsafe and that
> programmers increasingly do not use with any particular frequency. Unlike
> `move`, which works on *all object*s, automatic and non-automatic alike.
>
> That's the basic point that Sean is (or seems to be) making about your
> proposal. You cannot use your proposal without calling upon deep-magic
> levels of C++, like placement new and so forth. Your features is brittle,
> incomplete, and painful to use.
>
> Allow me to restate your asinine "scalpel" analogy/conversation to better
> explain this:
>
> Surgeon: I propose this new scalpel, which does these things better than
>> the old scalpel.
>> Committee: But it doesn't do things better than the old scalpel. It
>> doesn't even work most of the time.
>> Surgeon: Sure it does. See, it works just fine if you stand on your head,
>> and it does things even better than the old one.
>> Committee: But... most people stopped performing surgery while standing
>> on their head years ago.
>> Surgeon: Isn't it up to the surgeon to decide how he wants to perform
>> surgery?
>> Committee: That's old style thinking. In modern surgery, we want tools
>> that work with how we actually operate on people, not tools that force us
>> to operate in a specific way. Especially ones known to be bad.
>> Surgeon: But the old scalpel has no such protections either. The old
>> scalpel is just... a scalpel.
>> Committee: That's not true at all. The old scalpel works just fine when
>> standing normally.
>> Surgeon: How would we even design a scalpel that does what this does
>> without having to stand on your head?
>> Committee: Put some effort into it, rather than doing the bare minimum
>> that you feel you can get away with. Make a *complete* scalpel.
>>
>
> In this analogy, "stand on your head" mean "using new/delete or placement
> new and explicit destructor calls".
>
> Indeed, it's not clear to me why it is that your proposal needs to be a
> language feature at all. N4034 was able to do what you're talking about
> purely as a standard library thing. All it would need to do is say that the
> function ends the lifetime of the source object, and that the source object
> must not be an automatic object.
>
> You can even have implicitly generated versions which will simply perform
> a move from the source to the destination, followed by a destructor call on
> the source. It would be deleted for any type `T` who's move constructor is
> not `noexcept`.
>

--
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/cad96977-d5d4-4eea-8169-ae1ceb8b6477%40isocpp.org.

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

<div dir=3D"ltr"><div>Nicol -=C2=A0the content of your response is no less =
ego-based than you claim mine is. You are deeply annoyed both by me as a pe=
rson, and by what I am trying to do.</div><div><br></div><div>As far as I c=
an tell, this annoyance seems to be based on misunderstandings. Perhaps=C2=
=A0like this:</div><div><br></div><div><br></div><div>&gt; If your relocati=
on support can&#39;t even perform relocation in this most simple of cases:<=
br></div><div><br></div><div>How does it <em>not</em> handle that case? If =
std::list has a relocator, the compiler can just call the relocator in this=
 case:</div><div><font color=3D"#666600"><br></font></div><div><font color=
=3D"#666600"><pre style=3D"background: rgb(246, 248, 255); color: rgb(0, 0,=
 32);">  <span style=3D"color: rgb(0, 102, 238);">std</span><span style=3D"=
color: rgb(64, 96, 128);">::</span><span style=3D"color: rgb(0, 48, 96);">l=
ist</span><span style=3D"color: rgb(64, 96, 128);">&lt;</span>T<span style=
=3D"color: rgb(64, 96, 128);">&gt;</span> SomeFunc<span style=3D"color: rgb=
(48, 128, 128);">(</span><span style=3D"color: rgb(48, 128, 128);">)</span>=
 <span style=3D"color: rgb(64, 96, 128);">{</span>
    <span style=3D"color: rgb(0, 102, 238);">std</span><span style=3D"color=
: rgb(64, 96, 128);">::</span><span style=3D"color: rgb(0, 48, 96);">list</=
span><span style=3D"color: rgb(64, 96, 128);">&lt;</span>T<span style=3D"co=
lor: rgb(64, 96, 128);">&gt;</span> lt <span style=3D"color: rgb(48, 128, 1=
28);">=3D</span> <span style=3D"color: rgb(48, 128, 128);">.</span><span st=
yle=3D"color: rgb(48, 128, 128);">.</span><span style=3D"color: rgb(48, 128=
, 128);">.</span>
    <span style=3D"color: rgb(48, 128, 128);">.</span><span style=3D"color:=
 rgb(48, 128, 128);">.</span><span style=3D"color: rgb(48, 128, 128);">.</s=
pan>
    <span style=3D"color: rgb(32, 0, 128); font-weight: bold;">return</span=
> lt<span style=3D"color: rgb(64, 96, 128);">;</span> <span style=3D"color:=
 rgb(89, 89, 121);">// no special syntax needed; compiler calls relocator &=
gt;&gt;list&lt;T&gt;</span>
  <span style=3D"color: rgb(64, 96, 128);">}</span>

</pre></font></div><div><br></div><div>What prevents the compiler from doin=
g this?</div><div><br></div><div><br></div><div><br>On Friday, April 8, 201=
6 at 8:12:03 AM UTC-6, Nicol Bolas wrote:</div><blockquote class=3D"gmail_q=
uote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-co=
lor: rgb(204, 204, 204); border-left-width: 1px; border-left-style: solid;"=
><div dir=3D"ltr">On Friday, April 8, 2016 at 2:07:17 AM UTC-4, <a>isocp...=
@denisbider.com</a> wrote:<blockquote class=3D"gmail_quote" style=3D"margin=
: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 20=
4); border-left-width: 1px; border-left-style: solid;"><div dir=3D"ltr"><di=
v>Ah, Jesus.</div><div><br></div><div>It seems to me C++ has become infeste=
d with people=C2=A0who call themselves &quot;modern&quot;, but whose=C2=A0o=
bjective is to=C2=A0desperately try to divorce=C2=A0the language=C2=A0from =
its low-level origins, while=C2=A0ashamedly having to=C2=A0recognize that t=
his cannot be done, because it would defeat the purpose of the language and=
 make it useless for its primary role.</div><div><br></div><div>You are now=
 building this over-ambitious standard library monstrosity, which is=C2=A0t=
rying to pretend that C++ can be a platform. But the=C2=A0role of C++ is no=
t to <i>be</i> a platform. It is a tool for <i>building</i> platforms, and =
for building applications on top of existing platforms.</div><div><br></div=
><div>I can honestly say I don&#39;t like what you&#39;re doing, and if you=
 keep going in this direction, C++ will have to be replaced with something =
that serves its original purpose.</div><div><br></div><div>Stop trying to m=
ake this a managed language, for god&#39;s sake.</div></div></blockquote><d=
iv><br>... So Sean points out how move support introduced a plethora of new=
 value categories in order to ensure that it does not get automatically use=
d in the wrong place. To make sure that it&#39;s reasonably safe and usable=
 for most programmers. And he suggests that you should investigate this sor=
t of thing as a way to make sure that your &quot;relocation&quot; is also r=
easonably safe, that it gets used automatically where appropriate, and that=
 it doesn&#39;t get used in improper places. And so forth.<br><br>And your =
response to this is <a onmousedown=3D"this.href=3D&#39;https://www.google.c=
om/url?q\75https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FAd_hominem\46sa\75D\46sn=
tz\0751\46usg\75AFQjCNG-BwifY9ygNjAtJUGk8AHKdjZJiQ&#39;;return true;" oncli=
ck=3D"this.href=3D&#39;https://www.google.com/url?q\75https%3A%2F%2Fen.wiki=
pedia.org%2Fwiki%2FAd_hominem\46sa\75D\46sntz\0751\46usg\75AFQjCNG-BwifY9yg=
NjAtJUGk8AHKdjZJiQ&#39;;return true;" href=3D"https://en.wikipedia.org/wiki=
/Ad_hominem" target=3D"_blank" rel=3D"nofollow">to claim that such commenta=
ry comes from people</a> who are &quot;infesting&quot; the language, that e=
ven that we make the language <i>as safe as it currently is</i> represents =
an attempt to &quot;make this a managed language&quot;, and so forth. You&#=
39;re basically saying that your design is perfect as is, and anyone who qu=
estions it in the name of safety is &quot;desperately try[ing] to divorce=
=C2=A0the language=C2=A0from its low-level origins.&quot;<br><br>Seriously,=
 are you <i>five-years old</i>?<br><br>And let&#39;s not forget the implied=
 insult to the standards committee that their design for move support is wr=
ong because it actually includes such safety features.<br><br>Personally, m=
y basic criticism of your proposal is that it&#39;s not even really half of=
 a proposal. You can only &quot;relocate&quot; objects who&#39;s lifetimes =
are governed by `new/delete` or placement new/explicit destructor calls. Th=
at is, not automatic objects. You&#39;re basically taking the <i>easy part<=
/i> of destructive move/relocation, and then pretending that you have a com=
plete &quot;relocation&quot; feature.<br><br>If your relocation support can=
&#39;t even perform relocation in this most simple of cases:<br><br><div st=
yle=3D"border: 1px solid rgb(187, 187, 187); border-image: none; -ms-word-w=
rap: break-word; background-color: rgb(250, 250, 250);"><code><div><span st=
yle=3D"color: rgb(0, 0, 0);">std</span><span style=3D"color: rgb(102, 102, =
0);">::</span><span style=3D"color: rgb(0, 0, 0);">list</span><span style=
=3D"color: rgb(102, 102, 0);">&lt;</span><span style=3D"color: rgb(0, 0, 0)=
;">T</span><span style=3D"color: rgb(102, 102, 0);">&gt;</span><span style=
=3D"color: rgb(0, 0, 0);"> </span><span style=3D"color: rgb(102, 0, 102);">=
SomeFunc</span><span style=3D"color: rgb(102, 102, 0);">()</span><span styl=
e=3D"color: rgb(0, 0, 0);"><br></span><span style=3D"color: rgb(102, 102, 0=
);">{</span><span style=3D"color: rgb(0, 0, 0);"><br>=C2=A0 std</span><span=
 style=3D"color: rgb(102, 102, 0);">::</span><span style=3D"color: rgb(0, 0=
, 0);">list</span><span style=3D"color: rgb(102, 102, 0);">&lt;</span><span=
 style=3D"color: rgb(0, 0, 0);">T</span><span style=3D"color: rgb(102, 102,=
 0);">&gt;</span><span style=3D"color: rgb(0, 0, 0);"> lt </span><span styl=
e=3D"color: rgb(102, 102, 0);">=3D</span><span style=3D"color: rgb(0, 0, 0)=
;"> </span><span style=3D"color: rgb(102, 102, 0);">...</span><span style=
=3D"color: rgb(0, 0, 0);"><br>=C2=A0 </span><span style=3D"color: rgb(102, =
102, 0);">...</span><span style=3D"color: rgb(0, 0, 0);"><br>=C2=A0 </span>=
<span style=3D"color: rgb(0, 0, 136);">return</span><span style=3D"color: r=
gb(0, 0, 0);"> lt</span><span style=3D"color: rgb(102, 102, 0);">;</span><s=
pan style=3D"color: rgb(0, 0, 0);"> </span><span style=3D"color: rgb(136, 0=
, 0);">//Insert syntax for relocation-returning, if needed</span><span styl=
e=3D"color: rgb(0, 0, 0);"><br></span><span style=3D"color: rgb(102, 102, 0=
);">}</span></div></code></div><br>Then <i>what good is it</i>?<br><br>In f=
act, there is <i>no way</i> in your proposal to relocate an object into a r=
eturn value. Not even with P0135&#39;s guaranteed elision mechanics. Since =
you can only relocate an object through the use of `new`, and return values=
 aren&#39;t created by `new`, there is no way to use relocation on simple r=
eturn values.<br><br>So again, <i>what good is this?</i><br><br>That&#39;s =
where the &quot;safety&quot; argument that Sean is making comes from. Your =
proposal only works with features that are inherently unsafe and that progr=
ammers increasingly do not use with any particular frequency. Unlike `move`=
, which works on <i>all object</i>s, automatic and non-automatic alike.<br>=
<br>That&#39;s the basic point that Sean is (or seems to be) making about y=
our proposal. You cannot use your proposal without calling upon deep-magic =
levels of C++, like placement new and so forth. Your features is brittle, i=
ncomplete, and painful to use.<br><br>Allow me to restate your asinine &quo=
t;scalpel&quot; analogy/conversation to better explain this:<br><br><blockq=
uote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left=
: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px; borde=
r-left-style: solid;">Surgeon: I propose this new scalpel, which does these=
 things better than the old scalpel.<br>Committee: But it doesn&#39;t do th=
ings better than the old scalpel. It doesn&#39;t even work most of the time=
..<br>Surgeon: Sure it does. See, it works just fine if you stand on your he=
ad, and it does things even better than the old one.<br>Committee: But... m=
ost people stopped performing surgery while standing on their head years ag=
o.<br>Surgeon: Isn&#39;t it up to the surgeon to decide how he wants to per=
form surgery?<br>Committee: That&#39;s old style thinking. In modern surger=
y, we want tools that work with how we actually operate on people, not tool=
s that force us to operate in a specific way. Especially ones known to be b=
ad.<br>Surgeon: But the old scalpel has no such protections either. The old=
 scalpel is just... a scalpel.<br>Committee: That&#39;s not true at all. Th=
e old scalpel works just fine when standing normally.<br>Surgeon: How would=
 we even design a scalpel that does what this does without having to stand =
on your head?<br>Committee: Put some effort into it, rather than doing the =
bare minimum that you feel you can get away with. Make a <i>complete</i> sc=
alpel.<br></blockquote><div><br>In this analogy, &quot;stand on your head&q=
uot; mean &quot;using new/delete or placement new and explicit destructor c=
alls&quot;.<br><br>Indeed, it&#39;s not clear to me why it is that your pro=
posal needs to be a=20
language feature at all. N4034 was able to do what you&#39;re talking about=
=20
purely as a standard library thing. All it would need to do is say that=20
the function ends the lifetime of the source object, and that the source
 object must not be an automatic object.<br><br>You can even have implicitl=
y generated versions which will simply perform a move from the source to th=
e destination, followed by a destructor call on the source. It would be del=
eted for any type `T` who&#39;s move constructor is not `noexcept`.<br></di=
v></div></div></blockquote></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/cad96977-d5d4-4eea-8169-ae1ceb8b6477%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/cad96977-d5d4-4eea-8169-ae1ceb8b6477=
%40isocpp.org</a>.<br />

------=_Part_955_1309426839.1460147137853--
------=_Part_954_388927962.1460147137852--

.

------=_Part_516_776133569.1460148395268
Content-Type: multipart/alternative;
 boundary="----=_Part_517_1178403751.1460148395269"

------=_Part_517_1178403751.1460148395269
Content-Type: text/plain; charset=UTF-8


>
> > If your relocation support can't even perform relocation in this most
> simple of cases:
>
> How does it *not* handle that case? If std::list has a relocator, the
> compiler can just call the relocator in this case:
>
>   std::list<T> SomeFunc() {
>     std::list<T> lt = ...
>     ...
>     return lt; // no special syntax needed; compiler calls relocator >>list<T>
>   }
>
>
> What prevents the compiler from doing this?
>

As far as I can tell, your proposal doesn't say anything about this case,
or about automatic objects at all. Your invocation section only addresses
the use-case of "relocating" one pointer to another.

You should take advantage of the feedback opportunity to improve your
proposal. There's no need to be so defensive.

--
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/456f6164-031c-4ccc-ba25-39fcb5714b98%40isocpp.org.

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

<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"><div>&gt; If =
your relocation support can&#39;t even perform relocation in this most simp=
le of cases:<br></div><div><br></div><div>How does it <em>not</em> handle t=
hat case? If std::list has a relocator, the compiler can just call the relo=
cator in this case:</div><div><font color=3D"#666600"><br></font></div><div=
><font color=3D"#666600"><pre style=3D"background:rgb(246,248,255);color:rg=
b(0,0,32)">  <span style=3D"color:rgb(0,102,238)">std</span><span style=3D"=
color:rgb(64,96,128)">::</span><span style=3D"color:rgb(0,48,96)">list</spa=
n><span style=3D"color:rgb(64,96,128)">&lt;</span>T<span style=3D"color:rgb=
(64,96,128)">&gt;</span> SomeFunc<span style=3D"color:rgb(48,128,128)">(</s=
pan><span style=3D"color:rgb(48,128,128)">)</span> <span style=3D"color:rgb=
(64,96,128)">{</span>
    <span style=3D"color:rgb(0,102,238)">std</span><span style=3D"color:rgb=
(64,96,128)">::</span><span style=3D"color:rgb(0,48,96)">list</span><span s=
tyle=3D"color:rgb(64,96,128)">&lt;</span>T<span style=3D"color:rgb(64,96,12=
8)">&gt;</span> lt <span style=3D"color:rgb(48,128,128)">=3D</span> <span s=
tyle=3D"color:rgb(48,128,128)">.</span><span style=3D"color:rgb(48,128,128)=
">.</span><span style=3D"color:rgb(48,128,128)">.</span>
    <span style=3D"color:rgb(48,128,128)">.</span><span style=3D"color:rgb(=
48,128,128)">.</span><span style=3D"color:rgb(48,128,128)">.</span>
    <span style=3D"color:rgb(32,0,128);font-weight:bold">return</span> lt<s=
pan style=3D"color:rgb(64,96,128)">;</span> <span style=3D"color:rgb(89,89,=
121)">// no special syntax needed; compiler calls relocator &gt;&gt;list&lt=
;T&gt;</span>
  <span style=3D"color:rgb(64,96,128)">}</span>

</pre></font></div><div><br></div><div>What prevents the compiler from doin=
g this?</div></div></blockquote><div><br></div><div>As far as I can tell, y=
our proposal doesn&#39;t say anything about this case, or about automatic o=
bjects at all. Your invocation section only addresses the use-case of &quot=
;relocating&quot; one pointer to another.=C2=A0</div><div><br></div><div>Yo=
u should take advantage of the feedback opportunity to improve your proposa=
l. There&#39;s no need to be so defensive.=C2=A0</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/456f6164-031c-4ccc-ba25-39fcb5714b98%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/456f6164-031c-4ccc-ba25-39fcb5714b98=
%40isocpp.org</a>.<br />

------=_Part_517_1178403751.1460148395269--
------=_Part_516_776133569.1460148395268--

.

------=_Part_949_1744695238.1460151863659
Content-Type: multipart/alternative;
 boundary="----=_Part_950_1736003873.1460151863659"

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

You are quite correct. This aspect is being implied, rather than being=20
addressed.
=20
I am toying with the following text - currently rather informal:

"Move optimization=20

When a type is relocatable; then in situations where an implementation=20
would otherwise move an object value to an object of same type by invoking=
=20
a move constructor, followed by destruction of the moved-from object; and=
=20
where no use of the moved-from object occurs between move and destruction;=
=20
the implementation may instead invoke the type=E2=80=99s relocator, eliding=
 the=20
move constructor and destructor.
This move optimization *must* occur when move construction followed by=20
destruction would otherwise be used when returning a relocatable type by=20
value from a function, into a new object of same type."

=20
This would require relocation for return by value, if relocation is=20
available and copy elision isn't. This would be similar to how move vs.=20
copy construction is already chosen right now.=20
=20
It would also open the door for a compiler to detect when an object is=20
being moved to a new location, followed by destruction in the previous=20
location. In this case, the compiler *could* use relocation (move=20
destruction), but is not forced to.
=20
An open concern here is whether this would be, in practice, too subtle. For=
=20
example, a developer might want to ensure that relocation is used, instead=
=20
of move construction + destruction:
=20

std::unique_ptr<Thing> MakeThing() {
  std::list<int> lst =3D ...;
  InitializeList(lst);
  return std::make_unique<Thing>(std::move(lst));
    // Is this copy construction, move construction, or relocation?}

=20
On the one hand, currently, we do not have syntax that the developer could=
=20
use to ensure move construction is used, rather than copy construction. The=
=20
developer just has to use syntax that allows for move construction, and=20
then count on that a move constructor is available.
=20
Suppose that we have relocation, and the compiler has determined to use=20
relocation in the above example.
=20
Then, someone modifies the above function as follows:
=20

std::unique_ptr<Thing> MakeThing() {
  std::list<int> lst =3D ...;
  InitializeList(lst);
  auto thing =3D std::make_unique<Thing>(std::move(lst));
  ReuseListForOtherPurpose(lst);
  return thing;}

=20
Now, this definitely no longer uses relocation, because *lst* is being used=
=20
again.

Is this a concern? How do we prevent this?

To avoid introducing a keyword, one way could be to add a blessed standard=
=20
library function, say *std::final_reference*:=20

std::unique_ptr<Thing> MakeThing() {
  std::list<int> lst =3D ...;
  InitializeList(lst);
  auto thing =3D std::make_unique<Thing>(std::final_reference(lst));
  ReuseListForOtherPurpose(lst);  // Error: use of "lst" after final_refere=
nce
  return thing;}


This would require a compiler to detect the reuse of "lst" after it's used=
=20
in *std::final_reference*, and flag an error when "lst" is reused.

An alternative to a blessed function would be a new keyword, e.g.=20
"final_reference".

Thoughts? Ideas?

=20
On Friday, April 8, 2016 at 2:46:35 PM UTC-6, barry....@gmail.com wrote:

> > If your relocation support can't even perform relocation in this most=
=20
>> simple of cases:
>> =20
>> =20
>> How does it *not* handle that case? If std::list has a relocator, the=20
>> compiler can just call the relocator in this case:
>> =20
>>
>>   std::list<T> SomeFunc() {
>>     std::list<T> lt =3D ...
>>     ...
>>     return lt; // no special syntax needed; compiler calls relocator >>l=
ist<T>
>>   }
>>
>> =20
>> What prevents the compiler from doing this?
>>
> =20
> As far as I can tell, your proposal doesn't say anything about this case,=
=20
> or about automatic objects at all. Your invocation section only addresses=
=20
> the use-case of "relocating" one pointer to another.=20
> =20
> You should take advantage of the feedback opportunity to improve your=20
> proposal. There's no need to be so defensive.=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/96061c41-6f44-468b-b5ec-fb1fd6fad4b7%40isocpp.or=
g.

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

<div dir=3D"ltr"><div>You are quite correct.=C2=A0This aspect is being impl=
ied, rather than being addressed.</div><div><div>=C2=A0</div></div><div>I a=
m toying with the following text - currently rather informal:</div><blockqu=
ote><h2 style=3D"margin: 12pt 0in 0pt;"><font color=3D"#2e74b5" face=3D"Cal=
ibri Light" size=3D"4">&quot;Move optimization</font></h2><font color=3D"#0=
00000" face=3D"Times New Roman" size=3D"3">

</font><p style=3D"margin: 8pt 0in; text-align: justify;"><font color=3D"#0=
00000" face=3D"Calibri" size=3D"3">When a type is relocatable; then
in situations where an implementation would otherwise move an object value =
to
an object of same type by invoking a move constructor, followed by destruct=
ion
of the moved-from object; and where no use of the moved-from object occurs =
between
move and destruction; the implementation may instead invoke the type=E2=80=
=99s relocator,
eliding the move constructor and destructor.</font></p><font color=3D"#0000=
00"><font face=3D"Times New Roman" size=3D"3">

</font><span style=3D"line-height: 107%; font-family: &quot;Calibri&quot;,s=
ans-serif; font-size: 11pt; mso-ascii-theme-font: minor-latin; mso-fareast-=
font-family: Calibri; mso-fareast-theme-font: minor-latin; mso-hansi-theme-=
font: minor-latin; mso-bidi-font-family: &quot;Times New Roman&quot;; mso-b=
idi-theme-font: minor-bidi; mso-ansi-language: EN-US; mso-fareast-language:=
 EN-US; mso-bidi-language: AR-SA;">This move optimization <b style=3D"mso-b=
idi-font-weight: normal;">must</b> occur when move construction followed by=
 destruction would otherwise
be used when returning a relocatable type by value from a function, into a =
new object
of same type.&quot;</span></font></blockquote><div>=C2=A0</div><div>This wo=
uld require relocation for return by value, if relocation is available and =
copy elision isn&#39;t. This would be similar to how move vs. copy construc=
tion is already chosen right now. </div><div><div>=C2=A0</div></div><div>It=
 would also open the door for a compiler to detect when an object is being =
moved to a new location, followed by destruction in the previous location.=
=C2=A0In this case, the compiler <em>could</em>=C2=A0use relocation (move d=
estruction), but is not forced to.</div><div><div>=C2=A0</div></div><div>An=
 open concern here is whether this would be, in practice, too subtle. For e=
xample, a developer might want to ensure that relocation is used, instead o=
f move construction + destruction:</div><div><div>=C2=A0</div></div><div><p=
re style=3D"background: rgb(246, 248, 255); color: rgb(0, 0, 32);"><span st=
yle=3D"color: rgb(89, 89, 121);"><pre style=3D"background: rgb(246, 248, 25=
5); color: rgb(0, 0, 32);"><span style=3D"color: rgb(0, 102, 238);">std</sp=
an><span style=3D"color: rgb(64, 96, 128);">::</span><span style=3D"color: =
rgb(0, 48, 96);">unique_ptr</span><span style=3D"color: rgb(64, 96, 128);">=
&lt;</span>Thing<span style=3D"color: rgb(64, 96, 128);">&gt;</span> MakeTh=
ing<span style=3D"color: rgb(48, 128, 128);">(</span><span style=3D"color: =
rgb(48, 128, 128);">)</span> <span style=3D"color: rgb(64, 96, 128);">{</sp=
an>
  <span style=3D"color: rgb(0, 102, 238);">std</span><span style=3D"color: =
rgb(64, 96, 128);">::</span><span style=3D"color: rgb(0, 48, 96);">list</sp=
an><span style=3D"color: rgb(64, 96, 128);">&lt;</span><span style=3D"color=
: rgb(32, 0, 128); font-weight: bold;">int</span><span style=3D"color: rgb(=
64, 96, 128);">&gt;</span> lst <span style=3D"color: rgb(48, 128, 128);">=
=3D</span> <span style=3D"color: rgb(48, 128, 128);">.</span><span style=3D=
"color: rgb(48, 128, 128);">.</span><span style=3D"color: rgb(48, 128, 128)=
;">.</span><span style=3D"color: rgb(64, 96, 128);">;</span>
  InitializeList<span style=3D"color: rgb(48, 128, 128);">(</span>lst<span =
style=3D"color: rgb(48, 128, 128);">)</span><span style=3D"color: rgb(64, 9=
6, 128);">;</span>
  <span style=3D"color: rgb(32, 0, 128); font-weight: bold;">return</span> =
<span style=3D"color: rgb(0, 102, 238);">std</span><span style=3D"color: rg=
b(64, 96, 128);">::</span>make_unique<span style=3D"color: rgb(64, 96, 128)=
;">&lt;</span>Thing<span style=3D"color: rgb(64, 96, 128);">&gt;</span><spa=
n style=3D"color: rgb(48, 128, 128);">(</span><span style=3D"color: rgb(0, =
102, 238);">std</span><span style=3D"color: rgb(64, 96, 128);">::</span><sp=
an style=3D"color: rgb(0, 48, 96);">move</span><span style=3D"color: rgb(48=
, 128, 128);">(</span>lst<span style=3D"color: rgb(48, 128, 128);">)</span>=
<span style=3D"color: rgb(48, 128, 128);">)</span><span style=3D"color: rgb=
(64, 96, 128);">;</span>
    <span style=3D"color: rgb(89, 89, 121);">// Is this copy construction, =
move construction, or relocation?</span>
<span style=3D"color: rgb(64, 96, 128);">}</span>

</pre></span></pre></div><div><div>=C2=A0</div></div><div>On the one hand, =
currently, we do not have syntax that the developer could use to ensure mov=
e construction is used,=C2=A0rather than=C2=A0copy construction. The develo=
per just has to use syntax that allows for move construction, and then coun=
t on that a move constructor is available.</div><div><div>=C2=A0</div></div=
><div>Suppose that we have relocation, and the compiler has determined to u=
se relocation in the above example.</div><div><div>=C2=A0</div></div><div>T=
hen, someone modifies=C2=A0the above=C2=A0function as follows:</div><div><d=
iv>=C2=A0</div></div><div><pre style=3D"background: rgb(246, 248, 255); col=
or: rgb(0, 0, 32);"><span style=3D"color: rgb(0, 102, 238);">std</span><spa=
n style=3D"color: rgb(64, 96, 128);">::</span><span style=3D"color: rgb(0, =
48, 96);">unique_ptr</span><span style=3D"color: rgb(64, 96, 128);">&lt;</s=
pan>Thing<span style=3D"color: rgb(64, 96, 128);">&gt;</span> MakeThing<spa=
n style=3D"color: rgb(48, 128, 128);">(</span><span style=3D"color: rgb(48,=
 128, 128);">)</span> <span style=3D"color: rgb(64, 96, 128);">{</span>
  <span style=3D"color: rgb(0, 102, 238);">std</span><span style=3D"color: =
rgb(64, 96, 128);">::</span><span style=3D"color: rgb(0, 48, 96);">list</sp=
an><span style=3D"color: rgb(64, 96, 128);">&lt;</span><span style=3D"color=
: rgb(32, 0, 128); font-weight: bold;">int</span><span style=3D"color: rgb(=
64, 96, 128);">&gt;</span> lst <span style=3D"color: rgb(48, 128, 128);">=
=3D</span> <span style=3D"color: rgb(48, 128, 128);">.</span><span style=3D=
"color: rgb(48, 128, 128);">.</span><span style=3D"color: rgb(48, 128, 128)=
;">.</span><span style=3D"color: rgb(64, 96, 128);">;</span>
  InitializeList<span style=3D"color: rgb(48, 128, 128);">(</span>lst<span =
style=3D"color: rgb(48, 128, 128);">)</span><span style=3D"color: rgb(64, 9=
6, 128);">;</span>
  <span style=3D"color: rgb(32, 0, 128); font-weight: bold;">auto</span> th=
ing <span style=3D"color: rgb(48, 128, 128);">=3D</span> <span style=3D"col=
or: rgb(0, 102, 238);">std</span><span style=3D"color: rgb(64, 96, 128);">:=
:</span>make_unique<span style=3D"color: rgb(64, 96, 128);">&lt;</span>Thin=
g<span style=3D"color: rgb(64, 96, 128);">&gt;</span><span style=3D"color: =
rgb(48, 128, 128);">(</span><span style=3D"color: rgb(0, 102, 238);">std</s=
pan><span style=3D"color: rgb(64, 96, 128);">::</span><span style=3D"color:=
 rgb(0, 48, 96);">move</span><span style=3D"color: rgb(48, 128, 128);">(</s=
pan>lst<span style=3D"color: rgb(48, 128, 128);">)</span><span style=3D"col=
or: rgb(48, 128, 128);">)</span><span style=3D"color: rgb(64, 96, 128);">;<=
/span>
  ReuseListForOtherPurpose<span style=3D"color: rgb(48, 128, 128);">(</span=
>lst<span style=3D"color: rgb(48, 128, 128);">)</span><span style=3D"color:=
 rgb(64, 96, 128);">;</span>
  <span style=3D"color: rgb(32, 0, 128); font-weight: bold;">return</span> =
thing<span style=3D"color: rgb(64, 96, 128);">;</span>
<span style=3D"color: rgb(64, 96, 128);">}</span>

</pre></div><div><div>=C2=A0</div></div><div><div>Now, this definitely no l=
onger uses relocation,=C2=A0because <em>lst</em> is being=C2=A0used again.<=
/div><div><br></div><div>Is this a concern? How do we prevent this?</div><d=
iv><br></div><div>To avoid introducing a keyword, one way could be to add a=
 blessed standard library function, say <em>std::final_reference</em>: </di=
v><div><br></div><div><pre style=3D"background: rgb(246, 248, 255); color: =
rgb(0, 0, 32);"><span style=3D"color: rgb(0, 102, 238);">std</span><span st=
yle=3D"color: rgb(64, 96, 128);">::</span><span style=3D"color: rgb(0, 48, =
96);">unique_ptr</span><span style=3D"color: rgb(64, 96, 128);">&lt;</span>=
Thing<span style=3D"color: rgb(64, 96, 128);">&gt;</span> MakeThing<span st=
yle=3D"color: rgb(48, 128, 128);">(</span><span style=3D"color: rgb(48, 128=
, 128);">)</span> <span style=3D"color: rgb(64, 96, 128);">{</span>
  <span style=3D"color: rgb(0, 102, 238);">std</span><span style=3D"color: =
rgb(64, 96, 128);">::</span><span style=3D"color: rgb(0, 48, 96);">list</sp=
an><span style=3D"color: rgb(64, 96, 128);">&lt;</span><span style=3D"color=
: rgb(32, 0, 128); font-weight: bold;">int</span><span style=3D"color: rgb(=
64, 96, 128);">&gt;</span> lst <span style=3D"color: rgb(48, 128, 128);">=
=3D</span> <span style=3D"color: rgb(48, 128, 128);">.</span><span style=3D=
"color: rgb(48, 128, 128);">.</span><span style=3D"color: rgb(48, 128, 128)=
;">.</span><span style=3D"color: rgb(64, 96, 128);">;</span>
  InitializeList<span style=3D"color: rgb(48, 128, 128);">(</span>lst<span =
style=3D"color: rgb(48, 128, 128);">)</span><span style=3D"color: rgb(64, 9=
6, 128);">;</span>
  <span style=3D"color: rgb(32, 0, 128); font-weight: bold;">auto</span> th=
ing <span style=3D"color: rgb(48, 128, 128);">=3D</span> <span style=3D"col=
or: rgb(0, 102, 238);">std</span><span style=3D"color: rgb(64, 96, 128);">:=
:</span>make_unique<span style=3D"color: rgb(64, 96, 128);">&lt;</span>Thin=
g<span style=3D"color: rgb(64, 96, 128);">&gt;</span><span style=3D"color: =
rgb(48, 128, 128);">(</span><span style=3D"color: rgb(0, 102, 238);">std</s=
pan><span style=3D"color: rgb(64, 96, 128);">::</span>final_reference<span =
style=3D"color: rgb(48, 128, 128);">(</span>lst<span style=3D"color: rgb(48=
, 128, 128);">)</span><span style=3D"color: rgb(48, 128, 128);">)</span><sp=
an style=3D"color: rgb(64, 96, 128);">;</span>
  ReuseListForOtherPurpose<span style=3D"color: rgb(48, 128, 128);">(</span=
>lst<span style=3D"color: rgb(48, 128, 128);">)</span><span style=3D"color:=
 rgb(64, 96, 128);">;</span>  <span style=3D"color: rgb(89, 89, 121);">// E=
rror: use of &quot;lst&quot; after final_reference</span>
  <span style=3D"color: rgb(32, 0, 128); font-weight: bold;">return</span> =
thing<span style=3D"color: rgb(64, 96, 128);">;</span>
<span style=3D"color: rgb(64, 96, 128);">}</span>

</pre></div><div><br></div></div><div><div>This would require a compiler to=
 detect the reuse of &quot;lst&quot; after it&#39;s used in=C2=A0<em>std::f=
inal_reference</em>, and flag an error when &quot;lst&quot; is reused.</div=
><div><br></div><div>An alternative to a blessed function would be a new ke=
yword, e.g. &quot;final_reference&quot;.</div><div><br></div><div>Thoughts?=
 Ideas?</div><div><br></div><div>=C2=A0</div></div><div><div>On Friday, Apr=
il 8, 2016 at 2:46:35 PM UTC-6, barry....@gmail.com wrote:</div></div><bloc=
kquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-le=
ft: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px; bor=
der-left-style: solid;"><blockquote class=3D"gmail_quote" style=3D"margin: =
0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204)=
; border-left-width: 1px; border-left-style: solid;"><div dir=3D"ltr"><div>=
&gt; If your relocation support can&#39;t even perform relocation in this m=
ost simple of cases:<div>=C2=A0</div></div><div><div>=C2=A0</div></div><div=
>How does it <em>not</em> handle that case? If std::list has a relocator, t=
he compiler can just call the relocator in this case:</div><div><font color=
=3D"#666600"></font><div><font color=3D"#666600"></font>=C2=A0</div></div><=
div><font color=3D"#666600"><pre style=3D"background: rgb(246, 248, 255); c=
olor: rgb(0, 0, 32);">  <span style=3D"color: rgb(0, 102, 238);">std</span>=
<span style=3D"color: rgb(64, 96, 128);">::</span><span style=3D"color: rgb=
(0, 48, 96);">list</span><span style=3D"color: rgb(64, 96, 128);">&lt;</spa=
n>T<span style=3D"color: rgb(64, 96, 128);">&gt;</span> SomeFunc<span style=
=3D"color: rgb(48, 128, 128);">(</span><span style=3D"color: rgb(48, 128, 1=
28);">)</span> <span style=3D"color: rgb(64, 96, 128);">{</span>
    <span style=3D"color: rgb(0, 102, 238);">std</span><span style=3D"color=
: rgb(64, 96, 128);">::</span><span style=3D"color: rgb(0, 48, 96);">list</=
span><span style=3D"color: rgb(64, 96, 128);">&lt;</span>T<span style=3D"co=
lor: rgb(64, 96, 128);">&gt;</span> lt <span style=3D"color: rgb(48, 128, 1=
28);">=3D</span> <span style=3D"color: rgb(48, 128, 128);">.</span><span st=
yle=3D"color: rgb(48, 128, 128);">.</span><span style=3D"color: rgb(48, 128=
, 128);">.</span>
    <span style=3D"color: rgb(48, 128, 128);">.</span><span style=3D"color:=
 rgb(48, 128, 128);">.</span><span style=3D"color: rgb(48, 128, 128);">.</s=
pan>
    <span style=3D"color: rgb(32, 0, 128); font-weight: bold;">return</span=
> lt<span style=3D"color: rgb(64, 96, 128);">;</span> <span style=3D"color:=
 rgb(89, 89, 121);">// no special syntax needed; compiler calls relocator &=
gt;&gt;list&lt;T&gt;</span>
  <span style=3D"color: rgb(64, 96, 128);">}</span>

</pre></font></div><div><div>=C2=A0</div></div><div>What prevents the compi=
ler from doing this?</div></div></blockquote><div><div>=C2=A0</div></div><d=
iv>As far as I can tell, your proposal doesn&#39;t say anything about this =
case, or about automatic objects at all. Your invocation section only addre=
sses the use-case of &quot;relocating&quot; one pointer to another.=C2=A0</=
div><div><div>=C2=A0</div></div><div>You should take advantage of the feedb=
ack opportunity to improve your proposal. There&#39;s no need to be so defe=
nsive.=C2=A0</div></blockquote></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/96061c41-6f44-468b-b5ec-fb1fd6fad4b7%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/96061c41-6f44-468b-b5ec-fb1fd6fad4b7=
%40isocpp.org</a>.<br />

------=_Part_950_1736003873.1460151863659--
------=_Part_949_1744695238.1460151863659--

.

------=_Part_1119_1497625205.1460154651741
Content-Type: multipart/alternative;
 boundary="----=_Part_1120_17427712.1460154651742"

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

Or, since we have this problem already when distinguishing between move and=
=20
copy construction: how about a family of special blessed functions, like=20
this?

template <typename T> T const& require_copy     (T const&);template <typena=
me T> T&&      require_move     (T&);template <typename T> T&       require=
_relocate (T&);


Each of these would require the compiler to flag the returned reference,=20
and perform a compile-time verification that the reference does in fact end=
=20
up being passed to a copy constructor; move constructor; or relocator,=20
respectively.

This would be useful even without relocate. It would allow code like this:

BigObj MakeBigObj() {
  BigObj x;
  x.This();
  x.That();
  return std::require_move(x);}


.... to verify that what's happening is indeed move construction - not copy=
=20
construction, by accident.


On Friday, April 8, 2016 at 3:44:24 PM UTC-6, isocp...@denisbider.com wrote=
:

> You are quite correct. This aspect is being implied, rather than being=20
> addressed.
> =20
> I am toying with the following text - currently rather informal:
>
> "Move optimization=20
>
> When a type is relocatable; then in situations where an implementation=20
> would otherwise move an object value to an object of same type by invokin=
g=20
> a move constructor, followed by destruction of the moved-from object; and=
=20
> where no use of the moved-from object occurs between move and destruction=
;=20
> the implementation may instead invoke the type=E2=80=99s relocator, elidi=
ng the=20
> move constructor and destructor.
> This move optimization *must* occur when move construction followed by=20
> destruction would otherwise be used when returning a relocatable type by=
=20
> value from a function, into a new object of same type."
>
> =20
> This would require relocation for return by value, if relocation is=20
> available and copy elision isn't. This would be similar to how move vs.=
=20
> copy construction is already chosen right now.=20
> =20
> It would also open the door for a compiler to detect when an object is=20
> being moved to a new location, followed by destruction in the previous=20
> location. In this case, the compiler *could* use relocation (move=20
> destruction), but is not forced to.
> =20
> An open concern here is whether this would be, in practice, too subtle.=
=20
> For example, a developer might want to ensure that relocation is used,=20
> instead of move construction + destruction:
> =20
>
> std::unique_ptr<Thing> MakeThing() {
>   std::list<int> lst =3D ...;
>   InitializeList(lst);
>   return std::make_unique<Thing>(std::move(lst));
>     // Is this copy construction, move construction, or relocation?}
>
> =20
> On the one hand, currently, we do not have syntax that the developer coul=
d=20
> use to ensure move construction is used, rather than copy construction. T=
he=20
> developer just has to use syntax that allows for move construction, and=
=20
> then count on that a move constructor is available.
> =20
> Suppose that we have relocation, and the compiler has determined to use=
=20
> relocation in the above example.
> =20
> Then, someone modifies the above function as follows:
> =20
>
> std::unique_ptr<Thing> MakeThing() {
>   std::list<int> lst =3D ...;
>   InitializeList(lst);
>   auto thing =3D std::make_unique<Thing>(std::move(lst));
>   ReuseListForOtherPurpose(lst);
>   return thing;}
>
> =20
> Now, this definitely no longer uses relocation, because *lst* is=20
> being used again.
>
> Is this a concern? How do we prevent this?
>
> To avoid introducing a keyword, one way could be to add a blessed standar=
d=20
> library function, say *std::final_reference*:=20
>
> std::unique_ptr<Thing> MakeThing() {
>   std::list<int> lst =3D ...;
>   InitializeList(lst);
>   auto thing =3D std::make_unique<Thing>(std::final_reference(lst));
>   ReuseListForOtherPurpose(lst);  // Error: use of "lst" after final_refe=
rence
>   return thing;}
>
>
> This would require a compiler to detect the reuse of "lst" after it's use=
d=20
> in *std::final_reference*, and flag an error when "lst" is reused.
>
> An alternative to a blessed function would be a new keyword, e.g.=20
> "final_reference".
>
> Thoughts? Ideas?
>
> =20
> On Friday, April 8, 2016 at 2:46:35 PM UTC-6, barry....@gmail.com wrote:
>
>> > If your relocation support can't even perform relocation in this most=
=20
>>> simple of cases:
>>> =20
>>> =20
>>> How does it *not* handle that case? If std::list has a relocator, the=
=20
>>> compiler can just call the relocator in this case:
>>> =20
>>>
>>>   std::list<T> SomeFunc() {
>>>     std::list<T> lt =3D ...
>>>     ...
>>>     return lt; // no special syntax needed; compiler calls relocator >>=
list<T>
>>>   }
>>>
>>> =20
>>> What prevents the compiler from doing this?
>>>
>> =20
>> As far as I can tell, your proposal doesn't say anything about this case=
,=20
>> or about automatic objects at all. Your invocation section only addresse=
s=20
>> the use-case of "relocating" one pointer to another.=20
>> =20
>> You should take advantage of the feedback opportunity to improve your=20
>> proposal. There's no need to be so defensive.=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/f92d4647-9aca-4471-bdc2-c7caba2e2128%40isocpp.or=
g.

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

<div dir=3D"ltr"><div>Or, since we have this problem already when distingui=
shing between move and copy construction: how=C2=A0about=C2=A0a family of=
=C2=A0special blessed functions, like this?</div><div><br></div><div><pre s=
tyle=3D"background: rgb(246, 248, 255); color: rgb(0, 0, 32);"><span style=
=3D"color: rgb(32, 0, 128); font-weight: bold;">template</span> <span style=
=3D"color: rgb(64, 96, 128);">&lt;</span><span style=3D"color: rgb(32, 0, 1=
28); font-weight: bold;">typename</span> T<span style=3D"color: rgb(64, 96,=
 128);">&gt;</span> T <span style=3D"color: rgb(32, 0, 128); font-weight: b=
old;">const</span><span style=3D"color: rgb(48, 128, 128);">&amp;</span> re=
quire_copy     <span style=3D"color: rgb(48, 128, 128);">(</span>T <span st=
yle=3D"color: rgb(32, 0, 128); font-weight: bold;">const</span><span style=
=3D"color: rgb(48, 128, 128);">&amp;</span><span style=3D"color: rgb(48, 12=
8, 128);">)</span><span style=3D"color: rgb(64, 96, 128);">;</span>
<span style=3D"color: rgb(32, 0, 128); font-weight: bold;">template</span> =
<span style=3D"color: rgb(64, 96, 128);">&lt;</span><span style=3D"color: r=
gb(32, 0, 128); font-weight: bold;">typename</span> T<span style=3D"color: =
rgb(64, 96, 128);">&gt;</span> T<span style=3D"color: rgb(48, 128, 128);">&=
amp;</span><span style=3D"color: rgb(48, 128, 128);">&amp;</span>      requ=
ire_move     <span style=3D"color: rgb(48, 128, 128);">(</span>T<span style=
=3D"color: rgb(48, 128, 128);">&amp;</span><span style=3D"color: rgb(48, 12=
8, 128);">)</span><span style=3D"color: rgb(64, 96, 128);">;</span>
<span style=3D"color: rgb(32, 0, 128); font-weight: bold;">template</span> =
<span style=3D"color: rgb(64, 96, 128);">&lt;</span><span style=3D"color: r=
gb(32, 0, 128); font-weight: bold;">typename</span> T<span style=3D"color: =
rgb(64, 96, 128);">&gt;</span> T<span style=3D"color: rgb(48, 128, 128);">&=
amp;</span>       require_relocate <span style=3D"color: rgb(48, 128, 128);=
">(</span>T<span style=3D"color: rgb(48, 128, 128);">&amp;</span><span styl=
e=3D"color: rgb(48, 128, 128);">)</span><span style=3D"color: rgb(64, 96, 1=
28);">;</span>

</pre></div><div><br></div><div>Each of these would require the compiler to=
 flag the returned reference, and perform a compile-time verification that =
the reference does in fact end up being passed to a copy constructor; move =
constructor; or relocator, respectively.</div><div><br></div><div>This woul=
d be useful even without relocate. It would allow code like this:</div><div=
><br></div><div><pre style=3D"background: rgb(246, 248, 255); color: rgb(0,=
 0, 32);">BigObj MakeBigObj<span style=3D"color: rgb(48, 128, 128);">(</spa=
n><span style=3D"color: rgb(48, 128, 128);">)</span> <span style=3D"color: =
rgb(64, 96, 128);">{</span>
  BigObj x<span style=3D"color: rgb(64, 96, 128);">;</span>
  x<span style=3D"color: rgb(48, 128, 128);">.</span>This<span style=3D"col=
or: rgb(48, 128, 128);">(</span><span style=3D"color: rgb(48, 128, 128);">)=
</span><span style=3D"color: rgb(64, 96, 128);">;</span>
  x<span style=3D"color: rgb(48, 128, 128);">.</span>That<span style=3D"col=
or: rgb(48, 128, 128);">(</span><span style=3D"color: rgb(48, 128, 128);">)=
</span><span style=3D"color: rgb(64, 96, 128);">;</span>
  <span style=3D"color: rgb(32, 0, 128); font-weight: bold;">return</span> =
<span style=3D"color: rgb(0, 102, 238);">std</span><span style=3D"color: rg=
b(64, 96, 128);">::</span>require_move<span style=3D"color: rgb(48, 128, 12=
8);">(</span>x<span style=3D"color: rgb(48, 128, 128);">)</span><span style=
=3D"color: rgb(64, 96, 128);">;</span>
<span style=3D"color: rgb(64, 96, 128);">}</span>

</pre></div><div><br></div><div>... to verify that what&#39;s happening is =
indeed move construction -=C2=A0not copy construction, by accident.<br></di=
v><div><br></div><div><br>On Friday, April 8, 2016 at 3:44:24 PM UTC-6, iso=
cp...@denisbider.com wrote:</div><blockquote class=3D"gmail_quote" style=3D=
"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, =
204, 204); border-left-width: 1px; border-left-style: solid;"><div dir=3D"l=
tr"><div>You are quite correct.=C2=A0This aspect is being implied, rather t=
han being addressed.</div><div><div>=C2=A0</div></div><div>I am toying with=
 the following text - currently rather informal:</div><blockquote><h2 style=
=3D"margin: 12pt 0in 0pt;"><font color=3D"#2e74b5" face=3D"Calibri Light" s=
ize=3D"4">&quot;Move optimization</font></h2><font color=3D"#000000" face=
=3D"Times New Roman" size=3D"3">

</font><p style=3D"margin: 8pt 0in; text-align: justify;"><font color=3D"#0=
00000" face=3D"Calibri" size=3D"3">When a type is relocatable; then
in situations where an implementation would otherwise move an object value =
to
an object of same type by invoking a move constructor, followed by destruct=
ion
of the moved-from object; and where no use of the moved-from object occurs =
between
move and destruction; the implementation may instead invoke the type=E2=80=
=99s relocator,
eliding the move constructor and destructor.</font></p><font color=3D"#0000=
00"><font face=3D"Times New Roman" size=3D"3">

</font><span style=3D"line-height: 107%; font-family: &quot;Calibri&quot;,s=
ans-serif; font-size: 11pt;">This move optimization <b>must</b> occur when =
move construction followed by destruction would otherwise
be used when returning a relocatable type by value from a function, into a =
new object
of same type.&quot;</span></font></blockquote><div>=C2=A0</div><div>This wo=
uld require relocation for return by value, if relocation is available and =
copy elision isn&#39;t. This would be similar to how move vs. copy construc=
tion is already chosen right now. </div><div><div>=C2=A0</div></div><div>It=
 would also open the door for a compiler to detect when an object is being =
moved to a new location, followed by destruction in the previous location.=
=C2=A0In this case, the compiler <em>could</em>=C2=A0use relocation (move d=
estruction), but is not forced to.</div><div><div>=C2=A0</div></div><div>An=
 open concern here is whether this would be, in practice, too subtle. For e=
xample, a developer might want to ensure that relocation is used, instead o=
f move construction + destruction:</div><div><div>=C2=A0</div></div><div><p=
re style=3D"background: rgb(246, 248, 255); color: rgb(0, 0, 32);"><span st=
yle=3D"color: rgb(89, 89, 121);"><pre style=3D"background: rgb(246, 248, 25=
5); color: rgb(0, 0, 32);"><span style=3D"color: rgb(0, 102, 238);">std</sp=
an><span style=3D"color: rgb(64, 96, 128);">::</span><span style=3D"color: =
rgb(0, 48, 96);">unique_ptr</span><span style=3D"color: rgb(64, 96, 128);">=
&lt;</span>Thing<span style=3D"color: rgb(64, 96, 128);">&gt;</span> MakeTh=
ing<span style=3D"color: rgb(48, 128, 128);">(</span><span style=3D"color: =
rgb(48, 128, 128);">)</span> <span style=3D"color: rgb(64, 96, 128);">{</sp=
an>
  <span style=3D"color: rgb(0, 102, 238);">std</span><span style=3D"color: =
rgb(64, 96, 128);">::</span><span style=3D"color: rgb(0, 48, 96);">list</sp=
an><span style=3D"color: rgb(64, 96, 128);">&lt;</span><span style=3D"color=
: rgb(32, 0, 128); font-weight: bold;">int</span><span style=3D"color: rgb(=
64, 96, 128);">&gt;</span> lst <span style=3D"color: rgb(48, 128, 128);">=
=3D</span> <span style=3D"color: rgb(48, 128, 128);">.</span><span style=3D=
"color: rgb(48, 128, 128);">.</span><span style=3D"color: rgb(48, 128, 128)=
;">.</span><span style=3D"color: rgb(64, 96, 128);">;</span>
  InitializeList<span style=3D"color: rgb(48, 128, 128);">(</span>lst<span =
style=3D"color: rgb(48, 128, 128);">)</span><span style=3D"color: rgb(64, 9=
6, 128);">;</span>
  <span style=3D"color: rgb(32, 0, 128); font-weight: bold;">return</span> =
<span style=3D"color: rgb(0, 102, 238);">std</span><span style=3D"color: rg=
b(64, 96, 128);">::</span>make_unique<span style=3D"color: rgb(64, 96, 128)=
;">&lt;</span>Thing<span style=3D"color: rgb(64, 96, 128);">&gt;</span><spa=
n style=3D"color: rgb(48, 128, 128);">(</span><span style=3D"color: rgb(0, =
102, 238);">std</span><span style=3D"color: rgb(64, 96, 128);">::</span><sp=
an style=3D"color: rgb(0, 48, 96);">m<wbr>ove</span><span style=3D"color: r=
gb(48, 128, 128);">(</span>lst<span style=3D"color: rgb(48, 128, 128);">)</=
span><span style=3D"color: rgb(48, 128, 128);">)</span><span style=3D"color=
: rgb(64, 96, 128);">;</span>
    <span style=3D"color: rgb(89, 89, 121);">// Is this copy construction, =
move construction, or relocation?</span>
<span style=3D"color: rgb(64, 96, 128);">}</span>

</pre></span></pre></div><div><div>=C2=A0</div></div><div>On the one hand, =
currently, we do not have syntax that the developer could use to ensure mov=
e construction is used,=C2=A0rather than=C2=A0copy construction. The develo=
per just has to use syntax that allows for move construction, and then coun=
t on that a move constructor is available.</div><div><div>=C2=A0</div></div=
><div>Suppose that we have relocation, and the compiler has determined to u=
se relocation in the above example.</div><div><div>=C2=A0</div></div><div>T=
hen, someone modifies=C2=A0the above=C2=A0function as follows:</div><div><d=
iv>=C2=A0</div></div><div><pre style=3D"background: rgb(246, 248, 255); col=
or: rgb(0, 0, 32);"><span style=3D"color: rgb(0, 102, 238);">std</span><spa=
n style=3D"color: rgb(64, 96, 128);">::</span><span style=3D"color: rgb(0, =
48, 96);">unique_ptr</span><span style=3D"color: rgb(64, 96, 128);">&lt;</s=
pan>Thing<span style=3D"color: rgb(64, 96, 128);">&gt;</span> MakeThing<spa=
n style=3D"color: rgb(48, 128, 128);">(</span><span style=3D"color: rgb(48,=
 128, 128);">)</span> <span style=3D"color: rgb(64, 96, 128);">{</span>
  <span style=3D"color: rgb(0, 102, 238);">std</span><span style=3D"color: =
rgb(64, 96, 128);">::</span><span style=3D"color: rgb(0, 48, 96);">list</sp=
an><span style=3D"color: rgb(64, 96, 128);">&lt;</span><span style=3D"color=
: rgb(32, 0, 128); font-weight: bold;">int</span><span style=3D"color: rgb(=
64, 96, 128);">&gt;</span> lst <span style=3D"color: rgb(48, 128, 128);">=
=3D</span> <span style=3D"color: rgb(48, 128, 128);">.</span><span style=3D=
"color: rgb(48, 128, 128);">.</span><span style=3D"color: rgb(48, 128, 128)=
;">.</span><span style=3D"color: rgb(64, 96, 128);">;</span>
  InitializeList<span style=3D"color: rgb(48, 128, 128);">(</span>lst<span =
style=3D"color: rgb(48, 128, 128);">)</span><span style=3D"color: rgb(64, 9=
6, 128);">;</span>
  <span style=3D"color: rgb(32, 0, 128); font-weight: bold;">auto</span> th=
ing <span style=3D"color: rgb(48, 128, 128);">=3D</span> <span style=3D"col=
or: rgb(0, 102, 238);">std</span><span style=3D"color: rgb(64, 96, 128);">:=
:</span>make_unique<span style=3D"color: rgb(64, 96, 128);">&lt;</span>Thin=
g<span style=3D"color: rgb(64, 96, 128);">&gt;</span><span style=3D"color: =
rgb(48, 128, 128);">(</span><span style=3D"color: rgb(0, 102, 238);">std</s=
pan><span style=3D"color: rgb(64, 96, 128);">::</span><span style=3D"color:=
 rgb(0, 48, 96);">m<wbr>ove</span><span style=3D"color: rgb(48, 128, 128);"=
>(</span>lst<span style=3D"color: rgb(48, 128, 128);">)</span><span style=
=3D"color: rgb(48, 128, 128);">)</span><span style=3D"color: rgb(64, 96, 12=
8);">;</span>
  ReuseListForOtherPurpose<span style=3D"color: rgb(48, 128, 128);">(</span=
>lst<span style=3D"color: rgb(48, 128, 128);">)</span><span style=3D"color:=
 rgb(64, 96, 128);">;</span>
  <span style=3D"color: rgb(32, 0, 128); font-weight: bold;">return</span> =
thing<span style=3D"color: rgb(64, 96, 128);">;</span>
<span style=3D"color: rgb(64, 96, 128);">}</span>

</pre></div><div><div>=C2=A0</div></div><div><div>Now, this definitely no l=
onger uses relocation,=C2=A0because <em>lst</em> is being=C2=A0used again.<=
/div><div><br></div><div>Is this a concern? How do we prevent this?</div><d=
iv><br></div><div>To avoid introducing a keyword, one way could be to add a=
 blessed standard library function, say <em>std::final_reference</em>: </di=
v><div><br></div><div><pre style=3D"background: rgb(246, 248, 255); color: =
rgb(0, 0, 32);"><span style=3D"color: rgb(0, 102, 238);">std</span><span st=
yle=3D"color: rgb(64, 96, 128);">::</span><span style=3D"color: rgb(0, 48, =
96);">unique_ptr</span><span style=3D"color: rgb(64, 96, 128);">&lt;</span>=
Thing<span style=3D"color: rgb(64, 96, 128);">&gt;</span> MakeThing<span st=
yle=3D"color: rgb(48, 128, 128);">(</span><span style=3D"color: rgb(48, 128=
, 128);">)</span> <span style=3D"color: rgb(64, 96, 128);">{</span>
  <span style=3D"color: rgb(0, 102, 238);">std</span><span style=3D"color: =
rgb(64, 96, 128);">::</span><span style=3D"color: rgb(0, 48, 96);">list</sp=
an><span style=3D"color: rgb(64, 96, 128);">&lt;</span><span style=3D"color=
: rgb(32, 0, 128); font-weight: bold;">int</span><span style=3D"color: rgb(=
64, 96, 128);">&gt;</span> lst <span style=3D"color: rgb(48, 128, 128);">=
=3D</span> <span style=3D"color: rgb(48, 128, 128);">.</span><span style=3D=
"color: rgb(48, 128, 128);">.</span><span style=3D"color: rgb(48, 128, 128)=
;">.</span><span style=3D"color: rgb(64, 96, 128);">;</span>
  InitializeList<span style=3D"color: rgb(48, 128, 128);">(</span>lst<span =
style=3D"color: rgb(48, 128, 128);">)</span><span style=3D"color: rgb(64, 9=
6, 128);">;</span>
  <span style=3D"color: rgb(32, 0, 128); font-weight: bold;">auto</span> th=
ing <span style=3D"color: rgb(48, 128, 128);">=3D</span> <span style=3D"col=
or: rgb(0, 102, 238);">std</span><span style=3D"color: rgb(64, 96, 128);">:=
:</span>make_unique<span style=3D"color: rgb(64, 96, 128);">&lt;</span>Thin=
g<span style=3D"color: rgb(64, 96, 128);">&gt;</span><span style=3D"color: =
rgb(48, 128, 128);">(</span><span style=3D"color: rgb(0, 102, 238);">std</s=
pan><span style=3D"color: rgb(64, 96, 128);">::</span>f<wbr>inal_reference<=
span style=3D"color: rgb(48, 128, 128);">(</span>lst<span style=3D"color: r=
gb(48, 128, 128);">)</span><span style=3D"color: rgb(48, 128, 128);">)</spa=
n><span style=3D"color: rgb(64, 96, 128);">;</span>
  ReuseListForOtherPurpose<span style=3D"color: rgb(48, 128, 128);">(</span=
>lst<span style=3D"color: rgb(48, 128, 128);">)</span><span style=3D"color:=
 rgb(64, 96, 128);">;</span>  <span style=3D"color: rgb(89, 89, 121);">// E=
rror: use of &quot;lst&quot; after final_reference</span>
  <span style=3D"color: rgb(32, 0, 128); font-weight: bold;">return</span> =
thing<span style=3D"color: rgb(64, 96, 128);">;</span>
<span style=3D"color: rgb(64, 96, 128);">}</span>

</pre></div><div><br></div></div><div><div>This would require a compiler to=
 detect the reuse of &quot;lst&quot; after it&#39;s used in=C2=A0<em>std::f=
inal_reference</em>, and flag an error when &quot;lst&quot; is reused.</div=
><div><br></div><div>An alternative to a blessed function would be a new ke=
yword, e.g. &quot;final_reference&quot;.</div><div><br></div><div>Thoughts?=
 Ideas?</div><div><br></div><div>=C2=A0</div></div><div><div>On Friday, Apr=
il 8, 2016 at 2:46:35 PM UTC-6, <a>barry....@gmail.com</a> wrote:</div></di=
v><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; pad=
ding-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1=
px; border-left-style: solid;"><blockquote class=3D"gmail_quote" style=3D"m=
argin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 20=
4, 204); border-left-width: 1px; border-left-style: solid;"><div dir=3D"ltr=
"><div>&gt; If your relocation support can&#39;t even perform relocation in=
 this most simple of cases:<div>=C2=A0</div></div><div><div>=C2=A0</div></d=
iv><div>How does it <em>not</em> handle that case? If std::list has a reloc=
ator, the compiler can just call the relocator in this case:</div><div><fon=
t color=3D"#666600"></font><div><font color=3D"#666600"></font>=C2=A0</div>=
</div><div><font color=3D"#666600"><pre style=3D"background: rgb(246, 248, =
255); color: rgb(0, 0, 32);">  <span style=3D"color: rgb(0, 102, 238);">std=
</span><span style=3D"color: rgb(64, 96, 128);">::</span><span style=3D"col=
or: rgb(0, 48, 96);">list</span><span style=3D"color: rgb(64, 96, 128);">&l=
t;</span>T<span style=3D"color: rgb(64, 96, 128);">&gt;</span> SomeFunc<spa=
n style=3D"color: rgb(48, 128, 128);">(</span><span style=3D"color: rgb(48,=
 128, 128);">)</span> <span style=3D"color: rgb(64, 96, 128);">{</span>
    <span style=3D"color: rgb(0, 102, 238);">std</span><span style=3D"color=
: rgb(64, 96, 128);">::</span><span style=3D"color: rgb(0, 48, 96);">list</=
span><span style=3D"color: rgb(64, 96, 128);">&lt;</span>T<span style=3D"co=
lor: rgb(64, 96, 128);">&gt;</span> lt <span style=3D"color: rgb(48, 128, 1=
28);">=3D</span> <span style=3D"color: rgb(48, 128, 128);">.</span><span st=
yle=3D"color: rgb(48, 128, 128);">.</span><span style=3D"color: rgb(48, 128=
, 128);">.</span>
    <span style=3D"color: rgb(48, 128, 128);">.</span><span style=3D"color:=
 rgb(48, 128, 128);">.</span><span style=3D"color: rgb(48, 128, 128);">.</s=
pan>
    <span style=3D"color: rgb(32, 0, 128); font-weight: bold;">return</span=
> lt<span style=3D"color: rgb(64, 96, 128);">;</span> <span style=3D"color:=
 rgb(89, 89, 121);">// no special syntax needed; compiler calls relocator &=
gt;&gt;list&lt;T&gt;</span>
  <span style=3D"color: rgb(64, 96, 128);">}</span>

</pre></font></div><div><div>=C2=A0</div></div><div>What prevents the compi=
ler from doing this?</div></div></blockquote><div><div>=C2=A0</div></div><d=
iv>As far as I can tell, your proposal doesn&#39;t say anything about this =
case, or about automatic objects at all. Your invocation section only addre=
sses the use-case of &quot;relocating&quot; one pointer to another.=C2=A0</=
div><div><div>=C2=A0</div></div><div>You should take advantage of the feedb=
ack opportunity to improve your proposal. There&#39;s no need to be so defe=
nsive.=C2=A0</div></blockquote></div></blockquote></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/f92d4647-9aca-4471-bdc2-c7caba2e2128%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/f92d4647-9aca-4471-bdc2-c7caba2e2128=
%40isocpp.org</a>.<br />

------=_Part_1120_17427712.1460154651742--
------=_Part_1119_1497625205.1460154651741--

.

------=_Part_1139_1556648077.1460174730295
Content-Type: multipart/alternative;
 boundary="----=_Part_1140_479930691.1460174730296"

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

I have uploaded a new version of the proposal:

http://denisbider.com/Relocator.pdf

Main changes:

- Indirect use of relocation via copy/move optimization is now explicitly=
=20
defined.

- There is a new annex, proposing a syntax by which a language user can=20
ensure that copy/move optimizations are done as intended.

The proposed new syntax helps not only with relocation, but also in=20
existing situations where a developer wants to ensure that deep copy is not=
=20
being accidentally used.

The proposed syntax simplifies the variant example as follows:

=20

  X temp { std::move(a.x) };

  b.y.~Y();

  *new* (&b.x) X(std::must_relocate(temp));

=20


It also allows for this:

=20

  BigPart MakeBigPart() {

    BigPart part;

    ...

    *return* std::must_move(part);     // may elide, relocate, or move -=20
but not copy

  }

=20

  std::unique_ptr<BigThing> MakeBigThing() {

    *auto* part =3D MakeBigPart();

    *auto* thng =3D std::make_unique<BigThing>(std::must_move(part));  //=
=20
relocate/move

    *return* thng;                     // do not care if copied

  }

=20

Comments welcome.


On Friday, April 8, 2016 at 4:30:52 PM UTC-6, isocp...@denisbider.com wrote=
:

> Or, since we have this problem already when distinguishing between move=
=20
> and copy construction: how about a family of special blessed functions,=
=20
> like this?
>
> template <typename T> T const& require_copy     (T const&);template <type=
name T> T&&      require_move     (T&);template <typename T> T&       requi=
re_relocate (T&);
>
>
> Each of these would require the compiler to flag the returned reference,=
=20
> and perform a compile-time verification that the reference does in fact e=
nd=20
> up being passed to a copy constructor; move constructor; or relocator,=20
> respectively.
>
> This would be useful even without relocate. It would allow code like this=
:
>
> BigObj MakeBigObj() {
>   BigObj x;
>   x.This();
>   x.That();
>   return std::require_move(x);}
>
>
> ... to verify that what's happening is indeed move construction - not cop=
y=20
> construction, by accident.
>
>
> On Friday, April 8, 2016 at 3:44:24 PM UTC-6, isocp...@denisbider.com=20
> wrote:
>
>> You are quite correct. This aspect is being implied, rather than being=
=20
>> addressed.
>> =20
>> I am toying with the following text - currently rather informal:
>>
>> "Move optimization=20
>>
>> When a type is relocatable; then in situations where an implementation=
=20
>> would otherwise move an object value to an object of same type by invoki=
ng=20
>> a move constructor, followed by destruction of the moved-from object; an=
d=20
>> where no use of the moved-from object occurs between move and destructio=
n;=20
>> the implementation may instead invoke the type=E2=80=99s relocator, elid=
ing the=20
>> move constructor and destructor.
>> This move optimization *must* occur when move construction followed by=
=20
>> destruction would otherwise be used when returning a relocatable type by=
=20
>> value from a function, into a new object of same type."
>>
>> =20
>> This would require relocation for return by value, if relocation is=20
>> available and copy elision isn't. This would be similar to how move vs.=
=20
>> copy construction is already chosen right now.=20
>> =20
>> It would also open the door for a compiler to detect when an object is=
=20
>> being moved to a new location, followed by destruction in the previous=
=20
>> location. In this case, the compiler *could* use relocation (move=20
>> destruction), but is not forced to.
>> =20
>> An open concern here is whether this would be, in practice, too subtle.=
=20
>> For example, a developer might want to ensure that relocation is used,=
=20
>> instead of move construction + destruction:
>> =20
>>
>> std::unique_ptr<Thing> MakeThing() {
>>   std::list<int> lst =3D ...;
>>   InitializeList(lst);
>>   return std::make_unique<Thing>(std::move(lst));
>>     // Is this copy construction, move construction, or relocation?}
>>
>> =20
>> On the one hand, currently, we do not have syntax that the developer=20
>> could use to ensure move construction is used, rather than copy=20
>> construction. The developer just has to use syntax that allows for move=
=20
>> construction, and then count on that a move constructor is available.
>> =20
>> Suppose that we have relocation, and the compiler has determined to use=
=20
>> relocation in the above example.
>> =20
>> Then, someone modifies the above function as follows:
>> =20
>>
>> std::unique_ptr<Thing> MakeThing() {
>>   std::list<int> lst =3D ...;
>>   InitializeList(lst);
>>   auto thing =3D std::make_unique<Thing>(std::move(lst));
>>   ReuseListForOtherPurpose(lst);
>>   return thing;}
>>
>> =20
>> Now, this definitely no longer uses relocation, because *lst* is=20
>> being used again.
>>
>> Is this a concern? How do we prevent this?
>>
>> To avoid introducing a keyword, one way could be to add a blessed=20
>> standard library function, say *std::final_reference*:=20
>>
>> std::unique_ptr<Thing> MakeThing() {
>>   std::list<int> lst =3D ...;
>>   InitializeList(lst);
>>   auto thing =3D std::make_unique<Thing>(std::final_reference(lst));
>>   ReuseListForOtherPurpose(lst);  // Error: use of "lst" after final_ref=
erence
>>   return thing;}
>>
>>
>> This would require a compiler to detect the reuse of "lst" after it's=20
>> used in *std::final_reference*, and flag an error when "lst" is reused.
>>
>> An alternative to a blessed function would be a new keyword, e.g.=20
>> "final_reference".
>>
>> Thoughts? Ideas?
>>
>> =20
>> On Friday, April 8, 2016 at 2:46:35 PM UTC-6, barry....@gmail.com wrote:
>>
>>> > If your relocation support can't even perform relocation in this most=
=20
>>>> simple of cases:
>>>> =20
>>>> =20
>>>> How does it *not* handle that case? If std::list has a relocator, the=
=20
>>>> compiler can just call the relocator in this case:
>>>> =20
>>>>
>>>>   std::list<T> SomeFunc() {
>>>>     std::list<T> lt =3D ...
>>>>     ...
>>>>     return lt; // no special syntax needed; compiler calls relocator >=
>list<T>
>>>>   }
>>>>
>>>> =20
>>>> What prevents the compiler from doing this?
>>>>
>>> =20
>>> As far as I can tell, your proposal doesn't say anything about this=20
>>> case, or about automatic objects at all. Your invocation section only=
=20
>>> addresses the use-case of "relocating" one pointer to another.=20
>>> =20
>>> You should take advantage of the feedback opportunity to improve your=
=20
>>> proposal. There's no need to be so defensive.=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/82db5d5a-bad9-42ce-b1ad-66bcc0dd20b0%40isocpp.or=
g.

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

<div dir=3D"ltr"><div>I have uploaded a new version of the proposal:</div><=
div><br></div><div><a href=3D"http://denisbider.com/Relocator.pdf">http://d=
enisbider.com/Relocator.pdf</a></div><div><br></div><div>Main changes:</div=
><div><br></div><div>- Indirect use of relocation via copy/move optimizatio=
n is now explicitly defined.</div><div><br></div><div>-=C2=A0There is a new=
=C2=A0annex, proposing=C2=A0a syntax by which a language user can ensure th=
at copy/move optimizations are done as intended.</div><div><br></div><div>T=
he proposed new syntax helps not only with relocation, but also in existing=
 situations where a developer wants to ensure that deep copy is not being a=
ccidentally used.</div><div><br></div><div>The proposed syntax simplifies t=
he variant example as follows:</div><div><br></div><div><pre style=3D"backg=
round: rgb(246, 248, 255); margin-top: 0in; vertical-align: middle;"><span =
style=3D"color: rgb(0, 0, 32); font-family: Consolas;"><font size=3D"2">=C2=
=A0</font></span></pre><pre style=3D"background: rgb(246, 248, 255); margin=
-top: 0in; vertical-align: middle;"><font size=3D"2"><span style=3D"color: =
rgb(0, 0, 32); font-family: Consolas;"><span style=3D"mso-spacerun: yes;">=
=C2=A0 </span>X temp </span><span style=3D"padding: 0in; border: 1pt window=
text; border-image: none; color: rgb(64, 96, 128); font-family: Consolas; m=
so-border-alt: none windowtext 0in;">{</span><span style=3D"color: rgb(0, 0=
, 32); font-family: Consolas;"> </span><span style=3D"padding: 0in; border:=
 1pt windowtext; border-image: none; color: rgb(0, 102, 238); font-family: =
Consolas; mso-border-alt: none windowtext 0in;">std</span><span style=3D"pa=
dding: 0in; border: 1pt windowtext; border-image: none; color: rgb(64, 96, =
128); font-family: Consolas; mso-border-alt: none windowtext 0in;">::</span=
><span style=3D"padding: 0in; border: 1pt windowtext; border-image: none; c=
olor: rgb(0, 48, 96); font-family: Consolas; mso-border-alt: none windowtex=
t 0in;">move</span><span style=3D"padding: 0in; border: 1pt windowtext; bor=
der-image: none; color: rgb(48, 128, 128); font-family: Consolas; mso-borde=
r-alt: none windowtext 0in;">(</span><span style=3D"color: rgb(0, 0, 32); f=
ont-family: Consolas;">a</span><span style=3D"padding: 0in; border: 1pt win=
dowtext; border-image: none; color: rgb(48, 128, 128); font-family: Consola=
s; mso-border-alt: none windowtext 0in;">.</span><span style=3D"color: rgb(=
0, 0, 32); font-family: Consolas;">x</span><span style=3D"padding: 0in; bor=
der: 1pt windowtext; border-image: none; color: rgb(48, 128, 128); font-fam=
ily: Consolas; mso-border-alt: none windowtext 0in;">)</span><span style=3D=
"color: rgb(0, 0, 32); font-family: Consolas;"> </span><span style=3D"paddi=
ng: 0in; border: 1pt windowtext; border-image: none; color: rgb(64, 96, 128=
); font-family: Consolas; mso-border-alt: none windowtext 0in;">};</span></=
font></pre><pre style=3D"background: rgb(246, 248, 255); margin-top: 0in; v=
ertical-align: middle;"><font size=3D"2"><span style=3D"color: rgb(0, 0, 32=
); font-family: Consolas;"> <span style=3D"mso-spacerun: yes;">=C2=A0</span=
>b</span><span style=3D"padding: 0in; border: 1pt windowtext; border-image:=
 none; color: rgb(48, 128, 128); font-family: Consolas; mso-border-alt: non=
e windowtext 0in;">.</span><span style=3D"color: rgb(0, 0, 32); font-family=
: Consolas;">y</span><span style=3D"padding: 0in; border: 1pt windowtext; b=
order-image: none; color: rgb(48, 128, 128); font-family: Consolas; mso-bor=
der-alt: none windowtext 0in;">.~</span><span style=3D"color: rgb(0, 0, 32)=
; font-family: Consolas;">Y</span><span style=3D"padding: 0in; border: 1pt =
windowtext; border-image: none; color: rgb(48, 128, 128); font-family: Cons=
olas; mso-border-alt: none windowtext 0in;">()</span><span style=3D"padding=
: 0in; border: 1pt windowtext; border-image: none; color: rgb(64, 96, 128);=
 font-family: Consolas; mso-border-alt: none windowtext 0in;">;</span></fon=
t></pre><pre style=3D"background: rgb(246, 248, 255); margin-top: 0in; vert=
ical-align: middle;"><font size=3D"2"><span style=3D"color: rgb(0, 0, 32); =
font-family: Consolas;"><span style=3D"mso-spacerun: yes;">=C2=A0 </span></=
span><b><span style=3D"padding: 0in; border: 1pt windowtext; border-image: =
none; color: rgb(32, 0, 128); font-family: Consolas; mso-border-alt: none w=
indowtext 0in;">new</span></b><span style=3D"color: rgb(0, 0, 32); font-fam=
ily: Consolas;"> </span><span style=3D"padding: 0in; border: 1pt windowtext=
; border-image: none; color: rgb(48, 128, 128); font-family: Consolas; mso-=
border-alt: none windowtext 0in;">(&amp;</span><span style=3D"color: rgb(0,=
 0, 32); font-family: Consolas;">b</span><span style=3D"padding: 0in; borde=
r: 1pt windowtext; border-image: none; color: rgb(48, 128, 128); font-famil=
y: Consolas; mso-border-alt: none windowtext 0in;">.</span><span style=3D"c=
olor: rgb(0, 0, 32); font-family: Consolas;">x</span><span style=3D"padding=
: 0in; border: 1pt windowtext; border-image: none; color: rgb(48, 128, 128)=
; font-family: Consolas; mso-border-alt: none windowtext 0in;">)</span><spa=
n style=3D"color: rgb(0, 0, 32); font-family: Consolas;"> X</span><span sty=
le=3D"padding: 0in; border: 1pt windowtext; border-image: none; color: rgb(=
48, 128, 128); font-family: Consolas; mso-border-alt: none windowtext 0in;"=
>(</span><span style=3D"padding: 0in; border: 1pt windowtext; border-image:=
 none; color: rgb(0, 102, 238); font-family: Consolas; mso-border-alt: none=
 windowtext 0in;">std</span><span style=3D"padding: 0in; border: 1pt window=
text; border-image: none; color: rgb(64, 96, 128); font-family: Consolas; m=
so-border-alt: none windowtext 0in;">::</span><span style=3D"padding: 0in; =
border: 1pt windowtext; border-image: none; color: rgb(0, 48, 96); font-fam=
ily: Consolas; mso-border-alt: none windowtext 0in;">must_relocate</span><s=
pan style=3D"padding: 0in; border: 1pt windowtext; border-image: none; colo=
r: rgb(48, 128, 128); font-family: Consolas; mso-border-alt: none windowtex=
t 0in;">(</span><span style=3D"color: rgb(0, 0, 32); font-family: Consolas;=
">temp</span><span style=3D"padding: 0in; border: 1pt windowtext; border-im=
age: none; color: rgb(48, 128, 128); font-family: Consolas; mso-border-alt:=
 none windowtext 0in;">))</span><span style=3D"padding: 0in; border: 1pt wi=
ndowtext; border-image: none; color: rgb(64, 96, 128); font-family: Consola=
s; mso-border-alt: none windowtext 0in;">;</span></font></pre><pre style=3D=
"background: rgb(246, 248, 255); margin-top: 0in; vertical-align: middle;">=
<span style=3D"color: rgb(0, 0, 32); font-family: Consolas;"><font size=3D"=
2">=C2=A0</font></span></pre></div><div><br></div><div>It also allows for t=
his:</div><div><br></div><div><font color=3D"#000000" face=3D"Times New Rom=
an" size=3D"3">

</font><p style=3D"background: rgb(246, 248, 255); margin: 0in 0in 0pt; lin=
e-height: normal; tab-stops: 45.8pt 91.6pt 137.4pt 183.2pt 229.0pt 274.8pt =
320.6pt 366.4pt 412.2pt 458.0pt 503.8pt 549.6pt 595.4pt 641.2pt 687.0pt 732=
..8pt;"><span style=3D"color: rgb(0, 0, 32); font-family: Consolas; font-siz=
e: 10pt; mso-fareast-font-family: &quot;Times New Roman&quot;;">=C2=A0</spa=
n></p><font color=3D"#000000" face=3D"Times New Roman" size=3D"3">

</font><p style=3D"background: rgb(246, 248, 255); margin: 0in 0in 0pt; lin=
e-height: normal; tab-stops: 45.8pt 91.6pt 137.4pt 183.2pt 229.0pt 274.8pt =
320.6pt 366.4pt 412.2pt 458.0pt 503.8pt 549.6pt 595.4pt 641.2pt 687.0pt 732=
..8pt;"><span style=3D"color: rgb(0, 0, 32); font-family: Consolas; font-siz=
e: 10pt; mso-fareast-font-family: &quot;Times New Roman&quot;;"><span style=
=3D"mso-spacerun: yes;">=C2=A0 </span>BigPart MakeBigPart</span><span style=
=3D"color: rgb(48, 128, 128); font-family: Consolas; font-size: 10pt; mso-f=
areast-font-family: &quot;Times New Roman&quot;;">()</span><span style=3D"c=
olor: rgb(0, 0, 32); font-family: Consolas; font-size: 10pt; mso-fareast-fo=
nt-family: &quot;Times New Roman&quot;;"> </span><span style=3D"color: rgb(=
64, 96, 128); font-family: Consolas; font-size: 10pt; mso-fareast-font-fami=
ly: &quot;Times New Roman&quot;;">{</span></p><font color=3D"#000000" face=
=3D"Times New Roman" size=3D"3">

</font><p style=3D"background: rgb(246, 248, 255); margin: 0in 0in 0pt; lin=
e-height: normal; tab-stops: 45.8pt 91.6pt 137.4pt 183.2pt 229.0pt 274.8pt =
320.6pt 366.4pt 412.2pt 458.0pt 503.8pt 549.6pt 595.4pt 641.2pt 687.0pt 732=
..8pt;"><span style=3D"color: rgb(0, 0, 32); font-family: Consolas; font-siz=
e: 10pt; mso-fareast-font-family: &quot;Times New Roman&quot;;"><span style=
=3D"mso-spacerun: yes;">=C2=A0</span><span style=3D"mso-spacerun: yes;">=C2=
=A0 </span><span style=3D"mso-spacerun: yes;">=C2=A0</span>BigPart part</sp=
an><span style=3D"color: rgb(64, 96, 128); font-family: Consolas; font-size=
: 10pt; mso-fareast-font-family: &quot;Times New Roman&quot;;">;</span></p>=
<font color=3D"#000000" face=3D"Times New Roman" size=3D"3">

</font><p style=3D"background: rgb(246, 248, 255); margin: 0in 0in 0pt; lin=
e-height: normal; tab-stops: 45.8pt 91.6pt 137.4pt 183.2pt 229.0pt 274.8pt =
320.6pt 366.4pt 412.2pt 458.0pt 503.8pt 549.6pt 595.4pt 641.2pt 687.0pt 732=
..8pt;"><span style=3D"color: rgb(0, 0, 32); font-family: Consolas; font-siz=
e: 10pt; mso-fareast-font-family: &quot;Times New Roman&quot;;"><span style=
=3D"mso-spacerun: yes;">=C2=A0 </span><span style=3D"mso-spacerun: yes;">=
=C2=A0=C2=A0</span>...</span></p><font color=3D"#000000" face=3D"Times New =
Roman" size=3D"3">

</font><p style=3D"background: rgb(246, 248, 255); margin: 0in 0in 0pt; lin=
e-height: normal; tab-stops: 45.8pt 91.6pt 137.4pt 183.2pt 229.0pt 274.8pt =
320.6pt 366.4pt 412.2pt 458.0pt 503.8pt 549.6pt 595.4pt 641.2pt 687.0pt 732=
..8pt;"><span style=3D"color: rgb(0, 0, 32); font-family: Consolas; font-siz=
e: 10pt; mso-fareast-font-family: &quot;Times New Roman&quot;;"><span style=
=3D"mso-spacerun: yes;">=C2=A0 </span><span style=3D"mso-spacerun: yes;">=
=C2=A0=C2=A0</span></span><b><span style=3D"color: rgb(32, 0, 128); font-fa=
mily: Consolas; font-size: 10pt; mso-fareast-font-family: &quot;Times New R=
oman&quot;;">return</span></b><span style=3D"color: rgb(0, 0, 32); font-fam=
ily: Consolas; font-size: 10pt; mso-fareast-font-family: &quot;Times New Ro=
man&quot;;"> </span><span style=3D"color: rgb(0, 102, 238); font-family: Co=
nsolas; font-size: 10pt; mso-fareast-font-family: &quot;Times New Roman&quo=
t;;">std</span><span style=3D"color: rgb(64, 96, 128); font-family: Consola=
s; font-size: 10pt; mso-fareast-font-family: &quot;Times New Roman&quot;;">=
::</span><span style=3D"color: rgb(0, 48, 96); font-family: Consolas; font-=
size: 10pt; mso-fareast-font-family: &quot;Times New Roman&quot;;">must_mov=
e</span><span style=3D"color: rgb(48, 128, 128); font-family: Consolas; fon=
t-size: 10pt; mso-fareast-font-family: &quot;Times New Roman&quot;;">(</spa=
n><span style=3D"color: rgb(0, 0, 32); font-family: Consolas; font-size: 10=
pt; mso-fareast-font-family: &quot;Times New Roman&quot;;">part</span><span=
 style=3D"color: rgb(48, 128, 128); font-family: Consolas; font-size: 10pt;=
 mso-fareast-font-family: &quot;Times New Roman&quot;;">)</span><span style=
=3D"color: rgb(64, 96, 128); font-family: Consolas; font-size: 10pt; mso-fa=
reast-font-family: &quot;Times New Roman&quot;;">;</span><span style=3D"col=
or: rgb(0, 0, 32); font-family: Consolas; font-size: 10pt; mso-fareast-font=
-family: &quot;Times New Roman&quot;;"><span style=3D"mso-spacerun: yes;">=
=C2=A0 </span><span style=3D"mso-spacerun: yes;">=C2=A0=C2=A0=C2=A0</span><=
/span><span style=3D"color: rgb(89, 89, 121); font-family: Consolas; font-s=
ize: 10pt; mso-fareast-font-family: &quot;Times New Roman&quot;;">// may el=
ide, relocate, or move - but not copy</span></p><font color=3D"#000000" fac=
e=3D"Times New Roman" size=3D"3">

</font><p style=3D"background: rgb(246, 248, 255); margin: 0in 0in 0pt; lin=
e-height: normal; tab-stops: 45.8pt 91.6pt 137.4pt 183.2pt 229.0pt 274.8pt =
320.6pt 366.4pt 412.2pt 458.0pt 503.8pt 549.6pt 595.4pt 641.2pt 687.0pt 732=
..8pt;"><span style=3D"color: rgb(64, 96, 128); font-family: Consolas; font-=
size: 10pt; mso-fareast-font-family: &quot;Times New Roman&quot;;"><span st=
yle=3D"mso-spacerun: yes;">=C2=A0 </span>}</span></p><font color=3D"#000000=
" face=3D"Times New Roman" size=3D"3">

</font><p style=3D"background: rgb(246, 248, 255); margin: 0in 0in 0pt; lin=
e-height: normal; tab-stops: 45.8pt 91.6pt 137.4pt 183.2pt 229.0pt 274.8pt =
320.6pt 366.4pt 412.2pt 458.0pt 503.8pt 549.6pt 595.4pt 641.2pt 687.0pt 732=
..8pt;"><span style=3D"color: rgb(0, 0, 32); font-family: Consolas; font-siz=
e: 10pt; mso-fareast-font-family: &quot;Times New Roman&quot;;">=C2=A0</spa=
n></p><font color=3D"#000000" face=3D"Times New Roman" size=3D"3">

</font><p style=3D"background: rgb(246, 248, 255); margin: 0in 0in 0pt; lin=
e-height: normal; tab-stops: 45.8pt 91.6pt 137.4pt 183.2pt 229.0pt 274.8pt =
320.6pt 366.4pt 412.2pt 458.0pt 503.8pt 549.6pt 595.4pt 641.2pt 687.0pt 732=
..8pt;"><span style=3D"color: rgb(0, 102, 238); font-family: Consolas; font-=
size: 10pt; mso-fareast-font-family: &quot;Times New Roman&quot;;"><span st=
yle=3D"mso-spacerun: yes;">=C2=A0 </span>std</span><span style=3D"color: rg=
b(64, 96, 128); font-family: Consolas; font-size: 10pt; mso-fareast-font-fa=
mily: &quot;Times New Roman&quot;;">::</span><span style=3D"color: rgb(0, 4=
8, 96); font-family: Consolas; font-size: 10pt; mso-fareast-font-family: &q=
uot;Times New Roman&quot;;">unique_ptr</span><span style=3D"color: rgb(64, =
96, 128); font-family: Consolas; font-size: 10pt; mso-fareast-font-family: =
&quot;Times New Roman&quot;;">&lt;</span><span style=3D"color: rgb(0, 0, 32=
); font-family: Consolas; font-size: 10pt; mso-fareast-font-family: &quot;T=
imes New Roman&quot;;">BigThing</span><span style=3D"color: rgb(64, 96, 128=
); font-family: Consolas; font-size: 10pt; mso-fareast-font-family: &quot;T=
imes New Roman&quot;;">&gt;</span><span style=3D"color: rgb(0, 0, 32); font=
-family: Consolas; font-size: 10pt; mso-fareast-font-family: &quot;Times Ne=
w Roman&quot;;"> MakeBigThing</span><span style=3D"color: rgb(48, 128, 128)=
; font-family: Consolas; font-size: 10pt; mso-fareast-font-family: &quot;Ti=
mes New Roman&quot;;">()</span><span style=3D"color: rgb(0, 0, 32); font-fa=
mily: Consolas; font-size: 10pt; mso-fareast-font-family: &quot;Times New R=
oman&quot;;"> </span><span style=3D"color: rgb(64, 96, 128); font-family: C=
onsolas; font-size: 10pt; mso-fareast-font-family: &quot;Times New Roman&qu=
ot;;">{</span></p><font color=3D"#000000" face=3D"Times New Roman" size=3D"=
3">

</font><p style=3D"background: rgb(246, 248, 255); margin: 0in 0in 0pt; lin=
e-height: normal; tab-stops: 45.8pt 91.6pt 137.4pt 183.2pt 229.0pt 274.8pt =
320.6pt 366.4pt 412.2pt 458.0pt 503.8pt 549.6pt 595.4pt 641.2pt 687.0pt 732=
..8pt;"><span style=3D"color: rgb(0, 0, 32); font-family: Consolas; font-siz=
e: 10pt; mso-fareast-font-family: &quot;Times New Roman&quot;;"><span style=
=3D"mso-spacerun: yes;">=C2=A0 </span><span style=3D"mso-spacerun: yes;">=
=C2=A0=C2=A0</span></span><b><span style=3D"color: rgb(32, 0, 128); font-fa=
mily: Consolas; font-size: 10pt; mso-fareast-font-family: &quot;Times New R=
oman&quot;;">auto</span></b><span style=3D"color: rgb(0, 0, 32); font-famil=
y: Consolas; font-size: 10pt; mso-fareast-font-family: &quot;Times New Roma=
n&quot;;"> part </span><span style=3D"color: rgb(48, 128, 128); font-family=
: Consolas; font-size: 10pt; mso-fareast-font-family: &quot;Times New Roman=
&quot;;">=3D</span><span style=3D"color: rgb(0, 0, 32); font-family: Consol=
as; font-size: 10pt; mso-fareast-font-family: &quot;Times New Roman&quot;;"=
> MakeBigPart</span><span style=3D"color: rgb(48, 128, 128); font-family: C=
onsolas; font-size: 10pt; mso-fareast-font-family: &quot;Times New Roman&qu=
ot;;">()</span><span style=3D"color: rgb(64, 96, 128); font-family: Consola=
s; font-size: 10pt; mso-fareast-font-family: &quot;Times New Roman&quot;;">=
;</span></p><font color=3D"#000000" face=3D"Times New Roman" size=3D"3">

</font><p style=3D"background: rgb(246, 248, 255); margin: 0in 0in 0pt; lin=
e-height: normal; tab-stops: 45.8pt 91.6pt 137.4pt 183.2pt 229.0pt 274.8pt =
320.6pt 366.4pt 412.2pt 458.0pt 503.8pt 549.6pt 595.4pt 641.2pt 687.0pt 732=
..8pt;"><span style=3D"color: rgb(0, 0, 32); font-family: Consolas; font-siz=
e: 10pt; mso-fareast-font-family: &quot;Times New Roman&quot;;"><span style=
=3D"mso-spacerun: yes;">=C2=A0 </span><span style=3D"mso-spacerun: yes;">=
=C2=A0=C2=A0</span></span><b><span style=3D"color: rgb(32, 0, 128); font-fa=
mily: Consolas; font-size: 10pt; mso-fareast-font-family: &quot;Times New R=
oman&quot;;">auto</span></b><span style=3D"color: rgb(0, 0, 32); font-famil=
y: Consolas; font-size: 10pt; mso-fareast-font-family: &quot;Times New Roma=
n&quot;;"> thng </span><span style=3D"color: rgb(48, 128, 128); font-family=
: Consolas; font-size: 10pt; mso-fareast-font-family: &quot;Times New Roman=
&quot;;">=3D</span><span style=3D"color: rgb(0, 0, 32); font-family: Consol=
as; font-size: 10pt; mso-fareast-font-family: &quot;Times New Roman&quot;;"=
> </span><span style=3D"color: rgb(0, 102, 238); font-family: Consolas; fon=
t-size: 10pt; mso-fareast-font-family: &quot;Times New Roman&quot;;">std</s=
pan><span style=3D"color: rgb(64, 96, 128); font-family: Consolas; font-siz=
e: 10pt; mso-fareast-font-family: &quot;Times New Roman&quot;;">::</span><s=
pan style=3D"color: rgb(0, 48, 96); font-family: Consolas; font-size: 10pt;=
 mso-fareast-font-family: &quot;Times New Roman&quot;;">make_unique</span><=
span style=3D"color: rgb(64, 96, 128); font-family: Consolas; font-size: 10=
pt; mso-fareast-font-family: &quot;Times New Roman&quot;;">&lt;</span><span=
 style=3D"color: rgb(0, 0, 32); font-family: Consolas; font-size: 10pt; mso=
-fareast-font-family: &quot;Times New Roman&quot;;">BigThing</span><span st=
yle=3D"color: rgb(64, 96, 128); font-family: Consolas; font-size: 10pt; mso=
-fareast-font-family: &quot;Times New Roman&quot;;">&gt;</span><span style=
=3D"color: rgb(48, 128, 128); font-family: Consolas; font-size: 10pt; mso-f=
areast-font-family: &quot;Times New Roman&quot;;">(</span><span style=3D"co=
lor: rgb(0, 102, 238); font-family: Consolas; font-size: 10pt; mso-fareast-=
font-family: &quot;Times New Roman&quot;;">std</span><span style=3D"color: =
rgb(64, 96, 128); font-family: Consolas; font-size: 10pt; mso-fareast-font-=
family: &quot;Times New Roman&quot;;">::</span><span style=3D"color: rgb(0,=
 48, 96); font-family: Consolas; font-size: 10pt; mso-fareast-font-family: =
&quot;Times New Roman&quot;;">must_move</span><span style=3D"color: rgb(48,=
 128, 128); font-family: Consolas; font-size: 10pt; mso-fareast-font-family=
: &quot;Times New Roman&quot;;">(</span><span style=3D"color: rgb(0, 0, 32)=
; font-family: Consolas; font-size: 10pt; mso-fareast-font-family: &quot;Ti=
mes New Roman&quot;;">part</span><span style=3D"color: rgb(48, 128, 128); f=
ont-family: Consolas; font-size: 10pt; mso-fareast-font-family: &quot;Times=
 New Roman&quot;;">))</span><span style=3D"color: rgb(64, 96, 128); font-fa=
mily: Consolas; font-size: 10pt; mso-fareast-font-family: &quot;Times New R=
oman&quot;;">;</span><span style=3D"color: rgb(89, 89, 121); font-family: C=
onsolas; font-size: 10pt; mso-fareast-font-family: &quot;Times New Roman&qu=
ot;;"><span style=3D"mso-spacerun: yes;">=C2=A0 </span>// relocate/move</sp=
an></p><font color=3D"#000000" face=3D"Times New Roman" size=3D"3">

</font><p style=3D"background: rgb(246, 248, 255); margin: 0in 0in 0pt; lin=
e-height: normal; tab-stops: 45.8pt 91.6pt 137.4pt 183.2pt 229.0pt 274.8pt =
320.6pt 366.4pt 412.2pt 458.0pt 503.8pt 549.6pt 595.4pt 641.2pt 687.0pt 732=
..8pt;"><span style=3D"color: rgb(0, 0, 32); font-family: Consolas; font-siz=
e: 10pt; mso-fareast-font-family: &quot;Times New Roman&quot;;"><span style=
=3D"mso-spacerun: yes;">=C2=A0 </span><span style=3D"mso-spacerun: yes;">=
=C2=A0=C2=A0</span></span><b><span style=3D"color: rgb(32, 0, 128); font-fa=
mily: Consolas; font-size: 10pt; mso-fareast-font-family: &quot;Times New R=
oman&quot;;">return</span></b><span style=3D"color: rgb(0, 0, 32); font-fam=
ily: Consolas; font-size: 10pt; mso-fareast-font-family: &quot;Times New Ro=
man&quot;;"> thng</span><span style=3D"color: rgb(64, 96, 128); font-family=
: Consolas; font-size: 10pt; mso-fareast-font-family: &quot;Times New Roman=
&quot;;">;<span style=3D"mso-spacerun: yes;">=C2=A0 </span><span style=3D"m=
so-spacerun: yes;">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0</span></span><=
span style=3D"color: rgb(89, 89, 121); font-family: Consolas; font-size: 10=
pt; mso-fareast-font-family: &quot;Times New Roman&quot;;">// do not care i=
f copied</span></p><font color=3D"#000000" face=3D"Times New Roman" size=3D=
"3">

</font><p style=3D"background: rgb(246, 248, 255); margin: 0in 0in 0pt; lin=
e-height: normal; tab-stops: 45.8pt 91.6pt 137.4pt 183.2pt 229.0pt 274.8pt =
320.6pt 366.4pt 412.2pt 458.0pt 503.8pt 549.6pt 595.4pt 641.2pt 687.0pt 732=
..8pt;"><span style=3D"color: rgb(64, 96, 128); font-family: Consolas; font-=
size: 10pt; mso-fareast-font-family: &quot;Times New Roman&quot;;"><span st=
yle=3D"mso-spacerun: yes;">=C2=A0 </span>}</span></p><font color=3D"#000000=
" face=3D"Times New Roman" size=3D"3">

</font><p style=3D"background: rgb(246, 248, 255); margin: 0in 0in 0pt; lin=
e-height: normal; tab-stops: 45.8pt 91.6pt 137.4pt 183.2pt 229.0pt 274.8pt =
320.6pt 366.4pt 412.2pt 458.0pt 503.8pt 549.6pt 595.4pt 641.2pt 687.0pt 732=
..8pt;"><span style=3D"color: rgb(0, 0, 32); font-family: Consolas; font-siz=
e: 10pt; mso-fareast-font-family: &quot;Times New Roman&quot;;">=C2=A0</spa=
n></p><font color=3D"#000000" face=3D"Times New Roman" size=3D"3">

</font></div><div><br></div><div>Comments welcome.</div><div><br></div><div=
><br></div><div>On Friday, April 8, 2016 at 4:30:52 PM UTC-6, isocp...@deni=
sbider.com wrote:</div><blockquote class=3D"gmail_quote" style=3D"margin: 0=
px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204);=
 border-left-width: 1px; border-left-style: solid;"><div dir=3D"ltr"><div>O=
r, since we have this problem already when distinguishing between move and =
copy construction: how=C2=A0about=C2=A0a family of=C2=A0special blessed fun=
ctions, like this?</div><div><br></div><div><pre style=3D"background: rgb(2=
46, 248, 255); color: rgb(0, 0, 32);"><span style=3D"color: rgb(32, 0, 128)=
; font-weight: bold;">template</span> <span style=3D"color: rgb(64, 96, 128=
);">&lt;</span><span style=3D"color: rgb(32, 0, 128); font-weight: bold;">t=
ypename</span> T<span style=3D"color: rgb(64, 96, 128);">&gt;</span> T <spa=
n style=3D"color: rgb(32, 0, 128); font-weight: bold;">const</span><span st=
yle=3D"color: rgb(48, 128, 128);">&amp;</span> require_copy     <span style=
=3D"color: rgb(48, 128, 128);">(</span>T <span style=3D"color: rgb(32, 0, 1=
28); font-weight: bold;">const</span><span style=3D"color: rgb(48, 128, 128=
);">&amp;</span><span style=3D"color: rgb(48, 128, 128);">)</span><span sty=
le=3D"color: rgb(64, 96, 128);">;</span>
<span style=3D"color: rgb(32, 0, 128); font-weight: bold;">template</span> =
<span style=3D"color: rgb(64, 96, 128);">&lt;</span><span style=3D"color: r=
gb(32, 0, 128); font-weight: bold;">typename</span> T<span style=3D"color: =
rgb(64, 96, 128);">&gt;</span> T<span style=3D"color: rgb(48, 128, 128);">&=
amp;</span><span style=3D"color: rgb(48, 128, 128);">&amp;</span>      requ=
ire_move     <span style=3D"color: rgb(48, 128, 128);">(</span>T<span style=
=3D"color: rgb(48, 128, 128);">&amp;</span><span style=3D"color: rgb(48, 12=
8, 128);">)</span><span style=3D"color: rgb(64, 96, 128);">;</span>
<span style=3D"color: rgb(32, 0, 128); font-weight: bold;">template</span> =
<span style=3D"color: rgb(64, 96, 128);">&lt;</span><span style=3D"color: r=
gb(32, 0, 128); font-weight: bold;">typename</span> T<span style=3D"color: =
rgb(64, 96, 128);">&gt;</span> T<span style=3D"color: rgb(48, 128, 128);">&=
amp;</span>       require_relocate <span style=3D"color: rgb(48, 128, 128);=
">(</span>T<span style=3D"color: rgb(48, 128, 128);">&amp;</span><span styl=
e=3D"color: rgb(48, 128, 128);">)</span><span style=3D"color: rgb(64, 96, 1=
28);">;</span>

</pre></div><div><br></div><div>Each of these would require the compiler to=
 flag the returned reference, and perform a compile-time verification that =
the reference does in fact end up being passed to a copy constructor; move =
constructor; or relocator, respectively.</div><div><br></div><div>This woul=
d be useful even without relocate. It would allow code like this:</div><div=
><br></div><div><pre style=3D"background: rgb(246, 248, 255); color: rgb(0,=
 0, 32);">BigObj MakeBigObj<span style=3D"color: rgb(48, 128, 128);">(</spa=
n><span style=3D"color: rgb(48, 128, 128);">)</span> <span style=3D"color: =
rgb(64, 96, 128);">{</span>
  BigObj x<span style=3D"color: rgb(64, 96, 128);">;</span>
  x<span style=3D"color: rgb(48, 128, 128);">.</span>This<span style=3D"col=
or: rgb(48, 128, 128);">(</span><span style=3D"color: rgb(48, 128, 128);">)=
</span><span style=3D"color: rgb(64, 96, 128);">;</span>
  x<span style=3D"color: rgb(48, 128, 128);">.</span>That<span style=3D"col=
or: rgb(48, 128, 128);">(</span><span style=3D"color: rgb(48, 128, 128);">)=
</span><span style=3D"color: rgb(64, 96, 128);">;</span>
  <span style=3D"color: rgb(32, 0, 128); font-weight: bold;">return</span> =
<span style=3D"color: rgb(0, 102, 238);">std</span><span style=3D"color: rg=
b(64, 96, 128);">::</span>require_move<span style=3D"color: rgb(48, 128, 12=
8);">(</span>x<span style=3D"color: rgb(48, 128, 128);">)</span><span style=
=3D"color: rgb(64, 96, 128);">;</span>
<span style=3D"color: rgb(64, 96, 128);">}</span>

</pre></div><div><br></div><div>... to verify that what&#39;s happening is =
indeed move construction -=C2=A0not copy construction, by accident.<br></di=
v><div><br></div><div><br>On Friday, April 8, 2016 at 3:44:24 PM UTC-6, <a>=
isocp...@denisbider.com</a> wrote:</div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rg=
b(204, 204, 204); border-left-width: 1px; border-left-style: solid;"><div d=
ir=3D"ltr"><div>You are quite correct.=C2=A0This aspect is being implied, r=
ather than being addressed.</div><div><div>=C2=A0</div></div><div>I am toyi=
ng with the following text - currently rather informal:</div><blockquote><h=
2 style=3D"margin: 12pt 0in 0pt;"><font color=3D"#2e74b5" face=3D"Calibri L=
ight" size=3D"4">&quot;Move optimization</font></h2><font color=3D"#000000"=
 face=3D"Times New Roman" size=3D"3">

</font><p style=3D"margin: 8pt 0in; text-align: justify;"><font color=3D"#0=
00000" face=3D"Calibri" size=3D"3">When a type is relocatable; then
in situations where an implementation would otherwise move an object value =
to
an object of same type by invoking a move constructor, followed by destruct=
ion
of the moved-from object; and where no use of the moved-from object occurs =
between
move and destruction; the implementation may instead invoke the type=E2=80=
=99s relocator,
eliding the move constructor and destructor.</font></p><font color=3D"#0000=
00"><font face=3D"Times New Roman" size=3D"3">

</font><span style=3D"line-height: 107%; font-family: &quot;Calibri&quot;,s=
ans-serif; font-size: 11pt;">This move optimization <b>must</b> occur when =
move construction followed by destruction would otherwise
be used when returning a relocatable type by value from a function, into a =
new object
of same type.&quot;</span></font></blockquote><div>=C2=A0</div><div>This wo=
uld require relocation for return by value, if relocation is available and =
copy elision isn&#39;t. This would be similar to how move vs. copy construc=
tion is already chosen right now. </div><div><div>=C2=A0</div></div><div>It=
 would also open the door for a compiler to detect when an object is being =
moved to a new location, followed by destruction in the previous location.=
=C2=A0In this case, the compiler <em>could</em>=C2=A0use relocation (move d=
estruction), but is not forced to.</div><div><div>=C2=A0</div></div><div>An=
 open concern here is whether this would be, in practice, too subtle. For e=
xample, a developer might want to ensure that relocation is used, instead o=
f move construction + destruction:</div><div><div>=C2=A0</div></div><div><p=
re style=3D"background: rgb(246, 248, 255); color: rgb(0, 0, 32);"><span st=
yle=3D"color: rgb(89, 89, 121);"><pre style=3D"background: rgb(246, 248, 25=
5); color: rgb(0, 0, 32);"><span style=3D"color: rgb(0, 102, 238);">std</sp=
an><span style=3D"color: rgb(64, 96, 128);">::</span><span style=3D"color: =
rgb(0, 48, 96);">unique_ptr</span><span style=3D"color: rgb(64, 96, 128);">=
&lt;</span>Thing<span style=3D"color: rgb(64, 96, 128);">&gt;</span> MakeTh=
ing<span style=3D"color: rgb(48, 128, 128);">(</span><span style=3D"color: =
rgb(48, 128, 128);">)</span> <span style=3D"color: rgb(64, 96, 128);">{</sp=
an>
  <span style=3D"color: rgb(0, 102, 238);">std</span><span style=3D"color: =
rgb(64, 96, 128);">::</span><span style=3D"color: rgb(0, 48, 96);">list</sp=
an><span style=3D"color: rgb(64, 96, 128);">&lt;</span><span style=3D"color=
: rgb(32, 0, 128); font-weight: bold;">int</span><span style=3D"color: rgb(=
64, 96, 128);">&gt;</span> lst <span style=3D"color: rgb(48, 128, 128);">=
=3D</span> <span style=3D"color: rgb(48, 128, 128);">.</span><span style=3D=
"color: rgb(48, 128, 128);">.</span><span style=3D"color: rgb(48, 128, 128)=
;">.</span><span style=3D"color: rgb(64, 96, 128);">;</span>
  InitializeList<span style=3D"color: rgb(48, 128, 128);">(</span>lst<span =
style=3D"color: rgb(48, 128, 128);">)</span><span style=3D"color: rgb(64, 9=
6, 128);">;</span>
  <span style=3D"color: rgb(32, 0, 128); font-weight: bold;">return</span> =
<span style=3D"color: rgb(0, 102, 238);">std</span><span style=3D"color: rg=
b(64, 96, 128);">::</span>make_unique<span style=3D"color: rgb(64, 96, 128)=
;">&lt;</span>Thing<span style=3D"color: rgb(64, 96, 128);">&gt;</span><spa=
n style=3D"color: rgb(48, 128, 128);">(</span><span style=3D"color: rgb(0, =
102, 238);">std</span><span style=3D"color: rgb(64, 96, 128);">::</span><sp=
an style=3D"color: rgb(0, 48, 96);">m<wbr>ove</span><span style=3D"color: r=
gb(48, 128, 128);">(</span>lst<span style=3D"color: rgb(48, 128, 128);">)</=
span><span style=3D"color: rgb(48, 128, 128);">)</span><span style=3D"color=
: rgb(64, 96, 128);">;</span>
    <span style=3D"color: rgb(89, 89, 121);">// Is this copy construction, =
move construction, or relocation?</span>
<span style=3D"color: rgb(64, 96, 128);">}</span>

</pre></span></pre></div><div><div>=C2=A0</div></div><div>On the one hand, =
currently, we do not have syntax that the developer could use to ensure mov=
e construction is used,=C2=A0rather than=C2=A0copy construction. The develo=
per just has to use syntax that allows for move construction, and then coun=
t on that a move constructor is available.</div><div><div>=C2=A0</div></div=
><div>Suppose that we have relocation, and the compiler has determined to u=
se relocation in the above example.</div><div><div>=C2=A0</div></div><div>T=
hen, someone modifies=C2=A0the above=C2=A0function as follows:</div><div><d=
iv>=C2=A0</div></div><div><pre style=3D"background: rgb(246, 248, 255); col=
or: rgb(0, 0, 32);"><span style=3D"color: rgb(0, 102, 238);">std</span><spa=
n style=3D"color: rgb(64, 96, 128);">::</span><span style=3D"color: rgb(0, =
48, 96);">unique_ptr</span><span style=3D"color: rgb(64, 96, 128);">&lt;</s=
pan>Thing<span style=3D"color: rgb(64, 96, 128);">&gt;</span> MakeThing<spa=
n style=3D"color: rgb(48, 128, 128);">(</span><span style=3D"color: rgb(48,=
 128, 128);">)</span> <span style=3D"color: rgb(64, 96, 128);">{</span>
  <span style=3D"color: rgb(0, 102, 238);">std</span><span style=3D"color: =
rgb(64, 96, 128);">::</span><span style=3D"color: rgb(0, 48, 96);">list</sp=
an><span style=3D"color: rgb(64, 96, 128);">&lt;</span><span style=3D"color=
: rgb(32, 0, 128); font-weight: bold;">int</span><span style=3D"color: rgb(=
64, 96, 128);">&gt;</span> lst <span style=3D"color: rgb(48, 128, 128);">=
=3D</span> <span style=3D"color: rgb(48, 128, 128);">.</span><span style=3D=
"color: rgb(48, 128, 128);">.</span><span style=3D"color: rgb(48, 128, 128)=
;">.</span><span style=3D"color: rgb(64, 96, 128);">;</span>
  InitializeList<span style=3D"color: rgb(48, 128, 128);">(</span>lst<span =
style=3D"color: rgb(48, 128, 128);">)</span><span style=3D"color: rgb(64, 9=
6, 128);">;</span>
  <span style=3D"color: rgb(32, 0, 128); font-weight: bold;">auto</span> th=
ing <span style=3D"color: rgb(48, 128, 128);">=3D</span> <span style=3D"col=
or: rgb(0, 102, 238);">std</span><span style=3D"color: rgb(64, 96, 128);">:=
:</span>make_unique<span style=3D"color: rgb(64, 96, 128);">&lt;</span>Thin=
g<span style=3D"color: rgb(64, 96, 128);">&gt;</span><span style=3D"color: =
rgb(48, 128, 128);">(</span><span style=3D"color: rgb(0, 102, 238);">std</s=
pan><span style=3D"color: rgb(64, 96, 128);">::</span><span style=3D"color:=
 rgb(0, 48, 96);">m<wbr>ove</span><span style=3D"color: rgb(48, 128, 128);"=
>(</span>lst<span style=3D"color: rgb(48, 128, 128);">)</span><span style=
=3D"color: rgb(48, 128, 128);">)</span><span style=3D"color: rgb(64, 96, 12=
8);">;</span>
  ReuseListForOtherPurpose<span style=3D"color: rgb(48, 128, 128);">(</span=
>lst<span style=3D"color: rgb(48, 128, 128);">)</span><span style=3D"color:=
 rgb(64, 96, 128);">;</span>
  <span style=3D"color: rgb(32, 0, 128); font-weight: bold;">return</span> =
thing<span style=3D"color: rgb(64, 96, 128);">;</span>
<span style=3D"color: rgb(64, 96, 128);">}</span>

</pre></div><div><div>=C2=A0</div></div><div><div>Now, this definitely no l=
onger uses relocation,=C2=A0because <em>lst</em> is being=C2=A0used again.<=
/div><div><br></div><div>Is this a concern? How do we prevent this?</div><d=
iv><br></div><div>To avoid introducing a keyword, one way could be to add a=
 blessed standard library function, say <em>std::final_reference</em>: </di=
v><div><br></div><div><pre style=3D"background: rgb(246, 248, 255); color: =
rgb(0, 0, 32);"><span style=3D"color: rgb(0, 102, 238);">std</span><span st=
yle=3D"color: rgb(64, 96, 128);">::</span><span style=3D"color: rgb(0, 48, =
96);">unique_ptr</span><span style=3D"color: rgb(64, 96, 128);">&lt;</span>=
Thing<span style=3D"color: rgb(64, 96, 128);">&gt;</span> MakeThing<span st=
yle=3D"color: rgb(48, 128, 128);">(</span><span style=3D"color: rgb(48, 128=
, 128);">)</span> <span style=3D"color: rgb(64, 96, 128);">{</span>
  <span style=3D"color: rgb(0, 102, 238);">std</span><span style=3D"color: =
rgb(64, 96, 128);">::</span><span style=3D"color: rgb(0, 48, 96);">list</sp=
an><span style=3D"color: rgb(64, 96, 128);">&lt;</span><span style=3D"color=
: rgb(32, 0, 128); font-weight: bold;">int</span><span style=3D"color: rgb(=
64, 96, 128);">&gt;</span> lst <span style=3D"color: rgb(48, 128, 128);">=
=3D</span> <span style=3D"color: rgb(48, 128, 128);">.</span><span style=3D=
"color: rgb(48, 128, 128);">.</span><span style=3D"color: rgb(48, 128, 128)=
;">.</span><span style=3D"color: rgb(64, 96, 128);">;</span>
  InitializeList<span style=3D"color: rgb(48, 128, 128);">(</span>lst<span =
style=3D"color: rgb(48, 128, 128);">)</span><span style=3D"color: rgb(64, 9=
6, 128);">;</span>
  <span style=3D"color: rgb(32, 0, 128); font-weight: bold;">auto</span> th=
ing <span style=3D"color: rgb(48, 128, 128);">=3D</span> <span style=3D"col=
or: rgb(0, 102, 238);">std</span><span style=3D"color: rgb(64, 96, 128);">:=
:</span>make_unique<span style=3D"color: rgb(64, 96, 128);">&lt;</span>Thin=
g<span style=3D"color: rgb(64, 96, 128);">&gt;</span><span style=3D"color: =
rgb(48, 128, 128);">(</span><span style=3D"color: rgb(0, 102, 238);">std</s=
pan><span style=3D"color: rgb(64, 96, 128);">::</span>f<wbr>inal_reference<=
span style=3D"color: rgb(48, 128, 128);">(</span>lst<span style=3D"color: r=
gb(48, 128, 128);">)</span><span style=3D"color: rgb(48, 128, 128);">)</spa=
n><span style=3D"color: rgb(64, 96, 128);">;</span>
  ReuseListForOtherPurpose<span style=3D"color: rgb(48, 128, 128);">(</span=
>lst<span style=3D"color: rgb(48, 128, 128);">)</span><span style=3D"color:=
 rgb(64, 96, 128);">;</span>  <span style=3D"color: rgb(89, 89, 121);">// E=
rror: use of &quot;lst&quot; after final_reference</span>
  <span style=3D"color: rgb(32, 0, 128); font-weight: bold;">return</span> =
thing<span style=3D"color: rgb(64, 96, 128);">;</span>
<span style=3D"color: rgb(64, 96, 128);">}</span>

</pre></div><div><br></div></div><div><div>This would require a compiler to=
 detect the reuse of &quot;lst&quot; after it&#39;s used in=C2=A0<em>std::f=
inal_reference</em>, and flag an error when &quot;lst&quot; is reused.</div=
><div><br></div><div>An alternative to a blessed function would be a new ke=
yword, e.g. &quot;final_reference&quot;.</div><div><br></div><div>Thoughts?=
 Ideas?</div><div><br></div><div>=C2=A0</div></div><div><div>On Friday, Apr=
il 8, 2016 at 2:46:35 PM UTC-6, <a>barry....@gmail.com</a> wrote:</div></di=
v><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; pad=
ding-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1=
px; border-left-style: solid;"><blockquote class=3D"gmail_quote" style=3D"m=
argin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 20=
4, 204); border-left-width: 1px; border-left-style: solid;"><div dir=3D"ltr=
"><div>&gt; If your relocation support can&#39;t even perform relocation in=
 this most simple of cases:<div>=C2=A0</div></div><div><div>=C2=A0</div></d=
iv><div>How does it <em>not</em> handle that case? If std::list has a reloc=
ator, the compiler can just call the relocator in this case:</div><div><fon=
t color=3D"#666600"></font><div><font color=3D"#666600"></font>=C2=A0</div>=
</div><div><font color=3D"#666600"><pre style=3D"background: rgb(246, 248, =
255); color: rgb(0, 0, 32);">  <span style=3D"color: rgb(0, 102, 238);">std=
</span><span style=3D"color: rgb(64, 96, 128);">::</span><span style=3D"col=
or: rgb(0, 48, 96);">list</span><span style=3D"color: rgb(64, 96, 128);">&l=
t;</span>T<span style=3D"color: rgb(64, 96, 128);">&gt;</span> SomeFunc<spa=
n style=3D"color: rgb(48, 128, 128);">(</span><span style=3D"color: rgb(48,=
 128, 128);">)</span> <span style=3D"color: rgb(64, 96, 128);">{</span>
    <span style=3D"color: rgb(0, 102, 238);">std</span><span style=3D"color=
: rgb(64, 96, 128);">::</span><span style=3D"color: rgb(0, 48, 96);">list</=
span><span style=3D"color: rgb(64, 96, 128);">&lt;</span>T<span style=3D"co=
lor: rgb(64, 96, 128);">&gt;</span> lt <span style=3D"color: rgb(48, 128, 1=
28);">=3D</span> <span style=3D"color: rgb(48, 128, 128);">.</span><span st=
yle=3D"color: rgb(48, 128, 128);">.</span><span style=3D"color: rgb(48, 128=
, 128);">.</span>
    <span style=3D"color: rgb(48, 128, 128);">.</span><span style=3D"color:=
 rgb(48, 128, 128);">.</span><span style=3D"color: rgb(48, 128, 128);">.</s=
pan>
    <span style=3D"color: rgb(32, 0, 128); font-weight: bold;">return</span=
> lt<span style=3D"color: rgb(64, 96, 128);">;</span> <span style=3D"color:=
 rgb(89, 89, 121);">// no special syntax needed; compiler calls relocator &=
gt;&gt;list&lt;T&gt;</span>
  <span style=3D"color: rgb(64, 96, 128);">}</span>

</pre></font></div><div><div>=C2=A0</div></div><div>What prevents the compi=
ler from doing this?</div></div></blockquote><div><div>=C2=A0</div></div><d=
iv>As far as I can tell, your proposal doesn&#39;t say anything about this =
case, or about automatic objects at all. Your invocation section only addre=
sses the use-case of &quot;relocating&quot; one pointer to another.=C2=A0</=
div><div><div>=C2=A0</div></div><div>You should take advantage of the feedb=
ack opportunity to improve your proposal. There&#39;s no need to be so defe=
nsive.=C2=A0</div></blockquote></div></blockquote></div></blockquote></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/82db5d5a-bad9-42ce-b1ad-66bcc0dd20b0%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/82db5d5a-bad9-42ce-b1ad-66bcc0dd20b0=
%40isocpp.org</a>.<br />

------=_Part_1140_479930691.1460174730296--
------=_Part_1139_1556648077.1460174730295--

.

------=_Part_1170_2059248401.1460311658407
Content-Type: multipart/alternative;
 boundary="----=_Part_1171_706801045.1460311658418"

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

On Friday, April 8, 2016 at 5:44:24 PM UTC-4, isocp...@denisbider.com wrote=
:
>
> You are quite correct. This aspect is being implied, rather than being=20
> addressed.
>

No, they are not implied. The term "implied" would suggest that there would=
=20
be even a cursory mention of something approaching this notion somewhere in=
=20
the proposal. Nothing of the like was mentioned by any of the text in that=
=20
document. Therefore, the correct term would seem to be "assumed", not=20
"implied".

But in either case, proposals should not have vital features be "implied".=
=20
Proposals, *especially* for exceedingly complex ones like yours, need to=20
actually state what the whole feature is, as clearly as possible. Formal=20
wording isn't necessary (at first), but vital elements of the feature need=
=20
something more than mere implication.

I am toying with the following text - currently rather informal:
>
> "Move optimization=20
>
> When a type is relocatable; then in situations where an implementation=20
> would otherwise move an object value to an object of same type by invokin=
g=20
> a move constructor, followed by destruction of the moved-from object; and=
=20
> where no use of the moved-from object occurs between move and destruction=
;=20
> the implementation may instead invoke the type=E2=80=99s relocator, elidi=
ng the=20
> move constructor and destructor.
> This move optimization *must* occur when move construction followed by=20
> destruction would otherwise be used when returning a relocatable type by=
=20
> value from a function, into a new object of same type."
>
> =20
> This would require relocation for return by value, if relocation is=20
> available and copy elision isn't. This would be similar to how move vs.=
=20
> copy construction is already chosen right now.=20
> =20
> It would also open the door for a compiler to detect when an object is=20
> being moved to a new location, followed by destruction in the previous=20
> location. In this case, the compiler *could* use relocation (move=20
> destruction), but is not forced to.
> =20
> An open concern here is whether this would be, in practice, too subtle.=
=20
> For example, a developer might want to ensure that relocation is used,=20
> instead of move construction + destruction:
>
=20
>
std::unique_ptr<Thing> MakeThing() {
>   std::list<int> lst =3D ...;
>   InitializeList(lst);
>   return std::make_unique<Thing>(std::move(lst));
>     // Is this copy construction, move construction, or relocation?}
>
> =20
> On the one hand, currently, we do not have syntax that the developer coul=
d=20
> use to ensure move construction is used, rather than copy construction.
>

No, but we have an assurance that if `Thing` is moveable, then it will use=
=20
move construction. That's all that is necessary. Remember: movement is an=
=20
*optimization* of copying. So if the author of `Thing` has decided that his=
=20
type will not benefit from a move constructor, then that's up to him and=20
the needs of `Thing`. For users of that type, we assume that we will get=20
the most efficient operation available for that type.

Or to put it another way, you shouldn't *care* if it's really doing a move=
=20
or a copy. You're simply giving the object the opportunity to make the=20
operation efficient.

The fundamental difference between movement and destructive move is that it=
=20
is two operations in one. It's a move followed by an ending of the lifetime=
=20
of the object. You can't ignore or postpone that destruction. It's not=20
merely an optimized move. It is a fundamentally different type of operation=
..

Therefore, if you ask for destructive move on a variable, you *must get it*=
..=20
That is, every type must be destructive moveable, even if that operation=20
will simply perform a move/copy followed by a destructor call. The only=20
types that are not destructive moveable are those types which are not=20
move/copyable at all.

Move is an optimized copy. Destructive move is an optimization as well. But=
=20
it's an optimization of an operation that current does not exist in C++. So=
=20
your idea is really 2 things:

1. Adding destructive movement as an operation which the user can invoke.=
=20
This also includes identifying all of the places where destructive movement=
=20
can be invoked automatically by the compiler.

2. Adding the ability to write specialized destructive move code on a=20
per-object basis. This also needs to include issues (which your paper=20
didn't handle) about the *order* of the destruction of member elements. C++=
=20
has a well-defined order that member subobjects are supposed to be=20
destroyed in. A destructor cannot interfere in that order. So neither=20
should a destructive move operation. Your example in your initial proposal=
=20
showed cases where you change the order of member subobject destruction.

The developer just has to use syntax that allows for move construction, and=
=20
> then count on that a move constructor is available.
> =20
> Suppose that we have relocation, and the compiler has determined to use=
=20
> relocation in the above example.
> =20
> Then, someone modifies the above function as follows:
> =20
>
> std::unique_ptr<Thing> MakeThing() {
>   std::list<int> lst =3D ...;
>   InitializeList(lst);
>   auto thing =3D std::make_unique<Thing>(std::move(lst));
>   ReuseListForOtherPurpose(lst);
>   return thing;}
>
> =20
> Now, this definitely no longer uses relocation, because *lst* is=20
> being used again.
>
> Is this a concern? How do we prevent this?
>
> To avoid introducing a keyword, one way could be to add a blessed standar=
d=20
> library function, say *std::final_reference*:=20
>
> std::unique_ptr<Thing> MakeThing() {
>   std::list<int> lst =3D ...;
>   InitializeList(lst);
>   auto thing =3D std::make_unique<Thing>(std::final_reference(lst));
>   ReuseListForOtherPurpose(lst);  // Error: use of "lst" after final_refe=
rence
>   return thing;}
>
>
> This would require a compiler to detect the reuse of "lst" after it's use=
d=20
> in *std::final_reference*, and flag an error when "lst" is reused.
>
> An alternative to a blessed function would be a new keyword, e.g.=20
> "final_reference".=20
>

> Thoughts? Ideas?
>

This is one of the big problems with destructive move as a concept.

When you explicitly invoke a destructive move, you are destroying the=20
object. But we normally don't allow you to directly destroy automatic=20
variables. Because the compiler is going to destroy them later. Permitting=
=20
the user to destroy automatic variables can get into all kinds of problems.

What if you invoke the destructive move on the variable conditionally? Does=
=20
the compiler need to keep around a hidden boolean variable to know if the=
=20
automatic variable has been destroyed? What if you invoke it as part of a=
=20
long expression, and C++'s undefined order of expression evaluation starts=
=20
getting in the way? And so forth.

Whether it's done by some standard library function or a language keyword,=
=20
these problems persist.

This is one of the reasons why you need to do more research on this topic.=
=20
This stuff has been discussed at length, and these issues (among others)=20
have been brought up before.

--=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/d67f8331-d920-415d-8f71-0af7397dd2c6%40isocpp.or=
g.

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

<div dir=3D"ltr">On Friday, April 8, 2016 at 5:44:24 PM UTC-4, isocp...@den=
isbider.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"=
ltr"><div>You are quite correct.=C2=A0This aspect is being implied, rather =
than being addressed.</div></div></blockquote><div><br>No, they are not imp=
lied. The term &quot;implied&quot; would suggest that there would be even a=
 cursory mention of something approaching this notion somewhere in the prop=
osal. Nothing of the like was mentioned by any of the text in that document=
.. Therefore, the correct term would seem to be &quot;assumed&quot;, not &qu=
ot;implied&quot;.<br><br>But in either case, proposals should not have vita=
l features be &quot;implied&quot;. Proposals, <i>especially</i> for exceedi=
ngly complex ones like yours, need to actually state what the whole feature=
 is, as clearly as possible. Formal wording isn&#39;t necessary (at first),=
 but vital elements of the feature need something more than mere implicatio=
n.<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"lt=
r"><div><div></div></div><div>I am toying with the following text - current=
ly rather informal:</div><blockquote><h2 style=3D"margin:12pt 0in 0pt"><fon=
t face=3D"Calibri Light" size=3D"4" color=3D"#2e74b5">&quot;Move optimizati=
on</font></h2><font face=3D"Times New Roman" size=3D"3" color=3D"#000000">

</font><p style=3D"margin:8pt 0in;text-align:justify"><font face=3D"Calibri=
" size=3D"3" color=3D"#000000">When a type is relocatable; then
in situations where an implementation would otherwise move an object value =
to
an object of same type by invoking a move constructor, followed by destruct=
ion
of the moved-from object; and where no use of the moved-from object occurs =
between
move and destruction; the implementation may instead invoke the type=E2=80=
=99s relocator,
eliding the move constructor and destructor.</font></p><font color=3D"#0000=
00"><font face=3D"Times New Roman" size=3D"3">

</font><span style=3D"line-height:107%;font-family:&quot;Calibri&quot;,sans=
-serif;font-size:11pt">This move optimization <b>must</b> occur when move c=
onstruction followed by destruction would otherwise
be used when returning a relocatable type by value from a function, into a =
new object
of same type.&quot;</span></font></blockquote><div>=C2=A0</div><div>This wo=
uld require relocation for return by value, if relocation is available and =
copy elision isn&#39;t. This would be similar to how move vs. copy construc=
tion is already chosen right now. </div><div><div>=C2=A0</div></div><div>It=
 would also open the door for a compiler to detect when an object is being =
moved to a new location, followed by destruction in the previous location.=
=C2=A0In this case, the compiler <i>could</i>=C2=A0use relocation (move des=
truction), but is not forced to.</div><div><div>=C2=A0</div></div><div>An o=
pen concern here is whether this would be, in practice, too subtle. For exa=
mple, a developer might want to ensure that relocation is used, instead of =
move construction + destruction:</div></div></blockquote><blockquote style=
=3D"margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); p=
adding-left: 1ex;" class=3D"gmail_quote"><div>=C2=A0</div></blockquote><blo=
ckquote 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><pre style=
=3D"background:rgb(246,248,255);color:rgb(0,0,32)"><span style=3D"color:rgb=
(89,89,121)"><pre style=3D"background:rgb(246,248,255);color:rgb(0,0,32)"><=
span style=3D"color:rgb(0,102,238)">std</span><span style=3D"color:rgb(64,9=
6,128)">::</span><span style=3D"color:rgb(0,48,96)">unique_ptr</span><span =
style=3D"color:rgb(64,96,128)">&lt;</span>Thing<span style=3D"color:rgb(64,=
96,128)">&gt;</span> MakeThing<span style=3D"color:rgb(48,128,128)">(</span=
><span style=3D"color:rgb(48,128,128)">)</span> <span style=3D"color:rgb(64=
,96,128)">{</span>
  <span style=3D"color:rgb(0,102,238)">std</span><span style=3D"color:rgb(6=
4,96,128)">::</span><span style=3D"color:rgb(0,48,96)">list</span><span sty=
le=3D"color:rgb(64,96,128)">&lt;</span><span style=3D"color:rgb(32,0,128);f=
ont-weight:bold">int</span><span style=3D"color:rgb(64,96,128)">&gt;</span>=
 lst <span style=3D"color:rgb(48,128,128)">=3D</span> <span style=3D"color:=
rgb(48,128,128)">.</span><span style=3D"color:rgb(48,128,128)">.</span><spa=
n style=3D"color:rgb(48,128,128)">.</span><span style=3D"color:rgb(64,96,12=
8)">;</span>
  InitializeList<span style=3D"color:rgb(48,128,128)">(</span>lst<span styl=
e=3D"color:rgb(48,128,128)">)</span><span style=3D"color:rgb(64,96,128)">;<=
/span>
  <span style=3D"color:rgb(32,0,128);font-weight:bold">return</span> <span =
style=3D"color:rgb(0,102,238)">std</span><span style=3D"color:rgb(64,96,128=
)">::</span>make_unique<span style=3D"color:rgb(64,96,128)">&lt;</span>Thin=
g<span style=3D"color:rgb(64,96,128)">&gt;</span><span style=3D"color:rgb(4=
8,128,128)">(</span><span style=3D"color:rgb(0,102,238)">std</span><span st=
yle=3D"color:rgb(64,96,128)">::</span><span style=3D"color:rgb(0,48,96)">m<=
wbr>ove</span><span style=3D"color:rgb(48,128,128)">(</span>lst<span style=
=3D"color:rgb(48,128,128)">)</span><span style=3D"color:rgb(48,128,128)">)<=
/span><span style=3D"color:rgb(64,96,128)">;</span>
    <span style=3D"color:rgb(89,89,121)">// Is this copy construction, move=
 construction, or relocation?</span>
<span style=3D"color:rgb(64,96,128)">}</span>

</pre></span></pre></div><div><div>=C2=A0</div></div><div>On the one hand, =
currently, we do not have syntax that the developer could use to ensure mov=
e construction is used,=C2=A0rather than=C2=A0copy construction.</div></div=
></blockquote><div><br>No, but we have an assurance that if `Thing` is move=
able, then it will use move construction. That&#39;s all that is necessary.=
 Remember: movement is an <i>optimization</i> of copying. So if the author =
of `Thing` has decided that his type will not benefit from a move construct=
or, then that&#39;s up to him and the needs of `Thing`. For users of that t=
ype, we assume that we will get the most efficient operation available for =
that type.<br><br>Or to put it another way, you shouldn&#39;t <i>care</i> i=
f it&#39;s really doing a move or a copy. You&#39;re simply giving the obje=
ct the opportunity to make the operation efficient.<br><br>The fundamental =
difference between movement and destructive move is that it is two operatio=
ns in one. It&#39;s a move followed by an ending of the lifetime of the obj=
ect. You can&#39;t ignore or postpone that destruction. It&#39;s not merely=
 an optimized move. It is a fundamentally different type of operation.<br><=
br>Therefore, if you ask for destructive move on a variable, you <i>must ge=
t it</i>. That is, every type must be destructive moveable, even if that op=
eration will simply perform a move/copy followed by a destructor call. The =
only types that are not destructive moveable are those types which are not =
move/copyable at all.<br><br>Move is an optimized copy. Destructive move is=
 an optimization as well. But it&#39;s an optimization of an operation that=
 current does not exist in C++. So your idea is really 2 things:<br><br>1. =
Adding destructive movement as an operation which the user can invoke. This=
 also includes identifying all of the places where destructive movement can=
 be invoked automatically by the compiler.<br><br>2. Adding the ability to =
write specialized destructive move code on a per-object basis. This also ne=
eds to include issues (which your paper didn&#39;t handle) about the <i>ord=
er</i> of the destruction of member elements. C++ has a well-defined order =
that member subobjects are supposed to be destroyed in. A destructor cannot=
 interfere in that order. So neither should a destructive move operation. Y=
our example in your initial proposal showed cases where you change the orde=
r of member subobject destruction.<br><br></div><blockquote class=3D"gmail_=
quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;pa=
dding-left: 1ex;"><div dir=3D"ltr"><div>The developer just has to use synta=
x that allows for move construction, and then count on that a move construc=
tor is available.</div><div><div>=C2=A0</div></div><div>Suppose that we hav=
e relocation, and the compiler has determined to use relocation in the abov=
e example.</div><div><div>=C2=A0</div></div><div>Then, someone modifies=C2=
=A0the above=C2=A0function as follows:</div><div><div>=C2=A0</div></div><di=
v><pre style=3D"background:rgb(246,248,255);color:rgb(0,0,32)"><span style=
=3D"color:rgb(0,102,238)">std</span><span style=3D"color:rgb(64,96,128)">::=
</span><span style=3D"color:rgb(0,48,96)">unique_ptr</span><span style=3D"c=
olor:rgb(64,96,128)">&lt;</span>Thing<span style=3D"color:rgb(64,96,128)">&=
gt;</span> MakeThing<span style=3D"color:rgb(48,128,128)">(</span><span sty=
le=3D"color:rgb(48,128,128)">)</span> <span style=3D"color:rgb(64,96,128)">=
{</span>
  <span style=3D"color:rgb(0,102,238)">std</span><span style=3D"color:rgb(6=
4,96,128)">::</span><span style=3D"color:rgb(0,48,96)">list</span><span sty=
le=3D"color:rgb(64,96,128)">&lt;</span><span style=3D"color:rgb(32,0,128);f=
ont-weight:bold">int</span><span style=3D"color:rgb(64,96,128)">&gt;</span>=
 lst <span style=3D"color:rgb(48,128,128)">=3D</span> <span style=3D"color:=
rgb(48,128,128)">.</span><span style=3D"color:rgb(48,128,128)">.</span><spa=
n style=3D"color:rgb(48,128,128)">.</span><span style=3D"color:rgb(64,96,12=
8)">;</span>
  InitializeList<span style=3D"color:rgb(48,128,128)">(</span>lst<span styl=
e=3D"color:rgb(48,128,128)">)</span><span style=3D"color:rgb(64,96,128)">;<=
/span>
  <span style=3D"color:rgb(32,0,128);font-weight:bold">auto</span> thing <s=
pan style=3D"color:rgb(48,128,128)">=3D</span> <span style=3D"color:rgb(0,1=
02,238)">std</span><span style=3D"color:rgb(64,96,128)">::</span>make_uniqu=
e<span style=3D"color:rgb(64,96,128)">&lt;</span>Thing<span style=3D"color:=
rgb(64,96,128)">&gt;</span><span style=3D"color:rgb(48,128,128)">(</span><s=
pan style=3D"color:rgb(0,102,238)">std</span><span style=3D"color:rgb(64,96=
,128)">::</span><span style=3D"color:rgb(0,48,96)">m<wbr>ove</span><span st=
yle=3D"color:rgb(48,128,128)">(</span>lst<span style=3D"color:rgb(48,128,12=
8)">)</span><span style=3D"color:rgb(48,128,128)">)</span><span style=3D"co=
lor:rgb(64,96,128)">;</span>
  ReuseListForOtherPurpose<span style=3D"color:rgb(48,128,128)">(</span>lst=
<span style=3D"color:rgb(48,128,128)">)</span><span style=3D"color:rgb(64,9=
6,128)">;</span>
  <span style=3D"color:rgb(32,0,128);font-weight:bold">return</span> thing<=
span style=3D"color:rgb(64,96,128)">;</span>
<span style=3D"color:rgb(64,96,128)">}</span>

</pre></div><div><div>=C2=A0</div></div><div><div>Now, this definitely no l=
onger uses relocation,=C2=A0because <i>lst</i> is being=C2=A0used again.</d=
iv><div><br></div><div>Is this a concern? How do we prevent this?</div><div=
><br></div><div>To avoid introducing a keyword, one way could be to add a b=
lessed standard library function, say <i>std::final_reference</i>: </div><d=
iv><br></div><div><pre style=3D"background:rgb(246,248,255);color:rgb(0,0,3=
2)"><span style=3D"color:rgb(0,102,238)">std</span><span style=3D"color:rgb=
(64,96,128)">::</span><span style=3D"color:rgb(0,48,96)">unique_ptr</span><=
span style=3D"color:rgb(64,96,128)">&lt;</span>Thing<span style=3D"color:rg=
b(64,96,128)">&gt;</span> MakeThing<span style=3D"color:rgb(48,128,128)">(<=
/span><span style=3D"color:rgb(48,128,128)">)</span> <span style=3D"color:r=
gb(64,96,128)">{</span>
  <span style=3D"color:rgb(0,102,238)">std</span><span style=3D"color:rgb(6=
4,96,128)">::</span><span style=3D"color:rgb(0,48,96)">list</span><span sty=
le=3D"color:rgb(64,96,128)">&lt;</span><span style=3D"color:rgb(32,0,128);f=
ont-weight:bold">int</span><span style=3D"color:rgb(64,96,128)">&gt;</span>=
 lst <span style=3D"color:rgb(48,128,128)">=3D</span> <span style=3D"color:=
rgb(48,128,128)">.</span><span style=3D"color:rgb(48,128,128)">.</span><spa=
n style=3D"color:rgb(48,128,128)">.</span><span style=3D"color:rgb(64,96,12=
8)">;</span>
  InitializeList<span style=3D"color:rgb(48,128,128)">(</span>lst<span styl=
e=3D"color:rgb(48,128,128)">)</span><span style=3D"color:rgb(64,96,128)">;<=
/span>
  <span style=3D"color:rgb(32,0,128);font-weight:bold">auto</span> thing <s=
pan style=3D"color:rgb(48,128,128)">=3D</span> <span style=3D"color:rgb(0,1=
02,238)">std</span><span style=3D"color:rgb(64,96,128)">::</span>make_uniqu=
e<span style=3D"color:rgb(64,96,128)">&lt;</span>Thing<span style=3D"color:=
rgb(64,96,128)">&gt;</span><span style=3D"color:rgb(48,128,128)">(</span><s=
pan style=3D"color:rgb(0,102,238)">std</span><span style=3D"color:rgb(64,96=
,128)">::</span>f<wbr>inal_reference<span style=3D"color:rgb(48,128,128)">(=
</span>lst<span style=3D"color:rgb(48,128,128)">)</span><span style=3D"colo=
r:rgb(48,128,128)">)</span><span style=3D"color:rgb(64,96,128)">;</span>
  ReuseListForOtherPurpose<span style=3D"color:rgb(48,128,128)">(</span>lst=
<span style=3D"color:rgb(48,128,128)">)</span><span style=3D"color:rgb(64,9=
6,128)">;</span>  <span style=3D"color:rgb(89,89,121)">// Error: use of &qu=
ot;lst&quot; after final_reference</span>
  <span style=3D"color:rgb(32,0,128);font-weight:bold">return</span> thing<=
span style=3D"color:rgb(64,96,128)">;</span>
<span style=3D"color:rgb(64,96,128)">}</span>

</pre></div><div><br></div></div><div><div>This would require a compiler to=
 detect the reuse of &quot;lst&quot; after it&#39;s used in=C2=A0<i>std::fi=
nal_reference</i>, and flag an error when &quot;lst&quot; is reused.</div><=
div><br></div><div>An alternative to a blessed function would be a new keyw=
ord, e.g. &quot;final_reference&quot;.=C2=A0</div></div></div></blockquote>=
<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"><div><div><br=
></div><div>Thoughts? Ideas?</div></div></div></blockquote><div><br>This is=
 one of the big problems with destructive move as a concept.<br><br>When yo=
u explicitly invoke a destructive move, you are destroying the object. But =
we normally don&#39;t allow you to directly destroy automatic variables. Be=
cause the compiler is going to destroy them later. Permitting the user to d=
estroy automatic variables can get into all kinds of problems.<br><br>What =
if you invoke the destructive move on the variable conditionally? Does the =
compiler need to keep around a hidden boolean variable to know if the autom=
atic variable has been destroyed? What if you invoke it as part of a long e=
xpression, and C++&#39;s undefined order of expression evaluation starts ge=
tting in the way? And so forth.<br><br>Whether it&#39;s done by some standa=
rd library function or a language keyword, these problems persist.<br><br>T=
his is one of the reasons why you need to do more research on this topic. T=
his stuff has been discussed at length, and these issues (among others) hav=
e been brought up before.<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/d67f8331-d920-415d-8f71-0af7397dd2c6%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/d67f8331-d920-415d-8f71-0af7397dd2c6=
%40isocpp.org</a>.<br />

------=_Part_1171_706801045.1460311658418--
------=_Part_1170_2059248401.1460311658407--

.

------=_Part_6220_1247268716.1469670256782
Content-Type: multipart/alternative;
 boundary="----=_Part_6221_970988934.1469670256783"

------=_Part_6221_970988934.1469670256783
Content-Type: text/plain; charset=UTF-8

Here is another option: require move constructors to be noexcept for use in
variants.

On Tuesday, April 5, 2016 at 7:58:18 PM UTC-4, isocp...@denisbider.com
wrote:
>
> A proposal has recently been floated:
>
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0308r0.html
>
> ... which proposes pilfering as a solution to the valueless variant
> problem.
>
> Please correct me if I'm wrong - my understanding of the valueless variant
> problem is that it arises if a move constructor throws during assignment
> and emplacement, such as this:
>
>   std::variant<X, Y> a = X();
>   std::variant<X, Y> b = Y();
>   try { b = std::move(a); }    // bad_alloc here
>   catch (std::bad_alloc) {}
>
>
> In this case, variant's assignment operator has to do something like this:
>
>   b.y.~Y();
>   new (&b.x) X(std::move(a.x));
>
>
> To avoid a valueless result in case of exception, one's first thought
> might be to move first into a temporary:
>
>   X temp { std::move(a.x) };
>   b.y.~Y();
>   new (&b.x) X(std::move(temp.x);
>
>
> Unfortunately, this does not gain anything. Now the second move
> constructor may throw, resulting in the same situation.
>
> However!
>
> If C++ implemented relocation, as described in this proposal P0023:
>
> http://denisbider.com/Relocator.pdf
>
> Then the solution involving a temporary would work:
>
>   std::aligned_storage_t<sizeof(X), alignof(X)> tempData;
>   X* temp = new (tempData) { std::move(a.x) };
>   b.y.~Y();
>   new (&b.x) >>X(*temp);
>
>
> This would now be exception-safe:
>
> - without requiring pilfering;
> - and without a potentially, but almost never, valueless variant.
>
> Food for thought?
>
> I believe the relocation proposal has so far not progressed for, at least,
> these two reasons:
>
> (1) Proposals require champions to travel to meetings to represent them.
> (2) I am not willing to travel for this proposal, because I think the C++
> committee should just do the right thing, independent of who travels to a
> meeting.
>
> The language should consider ideas based on their merit - not conditional
> on the appearance of valiant knights who will cross swamps and deserts, to
> rescue ideas from a castle. :-)
>
>
>

--
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/e9fdc297-6cb0-4b6e-84d3-bc0b04c003a6%40isocpp.org.

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

<div dir=3D"ltr">Here is another option: require move constructors to be no=
except for use in variants.<br><br>On Tuesday, April 5, 2016 at 7:58:18 PM =
UTC-4, isocp...@denisbider.com wrote:<blockquote class=3D"gmail_quote" styl=
e=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left:=
 1ex;"><div dir=3D"ltr"><div>A proposal has recently been floated:</div><di=
v><br></div><div><a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/pap=
ers/2016/p0308r0.html" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"th=
is.href=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.open-std.org=
%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2016%2Fp0308r0.html\x26sa\x3dD\x26s=
ntz\x3d1\x26usg\x3dAFQjCNHNLlrqQeeAqLCC-Xsesn7EEo8zPA&#39;;return true;" on=
click=3D"this.href=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.o=
pen-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2016%2Fp0308r0.html\x26s=
a\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHNLlrqQeeAqLCC-Xsesn7EEo8zPA&#39;;retur=
n true;">http://www.open-std.org/jtc1/<wbr>sc22/wg21/docs/papers/2016/<wbr>=
p0308r0.html</a></div><div><br></div><div>... which proposes pilfering as a=
 solution to the valueless variant problem.</div><div><br></div><div>Please=
 correct me if I&#39;m wrong - my understanding of the valueless variant pr=
oblem is that it arises if a move constructor throws during assignment and =
emplacement, such as this:</div><div><br></div><div><pre style=3D"backgroun=
d:rgb(246,248,255);color:rgb(0,0,32)">  <span style=3D"color:rgb(0,102,238)=
">std</span><span style=3D"color:rgb(64,96,128)">::</span>variant<span styl=
e=3D"color:rgb(64,96,128)">&lt;</span>X<span style=3D"color:rgb(48,128,128)=
">,</span> Y<span style=3D"color:rgb(64,96,128)">&gt;</span> a <span style=
=3D"color:rgb(48,128,128)">=3D</span> X<span style=3D"color:rgb(48,128,128)=
">(</span><span style=3D"color:rgb(48,128,128)">)</span><span style=3D"colo=
r:rgb(64,96,128)">;</span>
  <span style=3D"color:rgb(0,102,238)">std</span><span style=3D"color:rgb(6=
4,96,128)">::</span>variant<span style=3D"color:rgb(64,96,128)">&lt;</span>=
X<span style=3D"color:rgb(48,128,128)">,</span> Y<span style=3D"color:rgb(6=
4,96,128)">&gt;</span> b <span style=3D"color:rgb(48,128,128)">=3D</span> Y=
<span style=3D"color:rgb(48,128,128)">(</span><span style=3D"color:rgb(48,1=
28,128)">)</span><span style=3D"color:rgb(64,96,128)">;</span>
  <span style=3D"color:rgb(32,0,128);font-weight:bold">try</span> <span sty=
le=3D"color:rgb(64,96,128)">{</span> b <span style=3D"color:rgb(48,128,128)=
">=3D</span> <span style=3D"color:rgb(0,102,238)">std</span><span style=3D"=
color:rgb(64,96,128)">::</span><span style=3D"color:rgb(0,48,96)">move</spa=
n><span style=3D"color:rgb(48,128,128)">(</span>a<span style=3D"color:rgb(4=
8,128,128)">)</span><span style=3D"color:rgb(64,96,128)">;</span> <span sty=
le=3D"color:rgb(64,96,128)">}</span>    <span style=3D"color:rgb(89,89,121)=
">// bad_alloc here</span>
  <span style=3D"color:rgb(32,0,128);font-weight:bold">catch</span> <span s=
tyle=3D"color:rgb(48,128,128)">(</span><span style=3D"color:rgb(0,102,238)"=
>std</span><span style=3D"color:rgb(64,96,128)">::</span><span style=3D"col=
or:rgb(0,48,96)">bad_alloc</span><span style=3D"color:rgb(48,128,128)">)</s=
pan> <span style=3D"color:rgb(64,96,128)">{</span><span style=3D"color:rgb(=
64,96,128)">}</span>

</pre></div><div><br></div><div>In this case, variant&#39;s assignment oper=
ator has to do something like this:</div><div><br></div><div><pre style=3D"=
background:rgb(246,248,255);color:rgb(0,0,32)">  b<span style=3D"color:rgb(=
48,128,128)">.</span>y<span style=3D"color:rgb(48,128,128)">.</span><span s=
tyle=3D"color:rgb(48,128,128)">~</span>Y<span style=3D"color:rgb(48,128,128=
)">(</span><span style=3D"color:rgb(48,128,128)">)</span><span style=3D"col=
or:rgb(64,96,128)">;</span>
  <span style=3D"color:rgb(32,0,128);font-weight:bold">new</span> <span sty=
le=3D"color:rgb(48,128,128)">(</span><span style=3D"color:rgb(48,128,128)">=
&amp;</span>b<span style=3D"color:rgb(48,128,128)">.</span>x<span style=3D"=
color:rgb(48,128,128)">)</span> X<span style=3D"color:rgb(48,128,128)">(</s=
pan><span style=3D"color:rgb(0,102,238)">std</span><span style=3D"color:rgb=
(64,96,128)">::</span><span style=3D"color:rgb(0,48,96)">move</span><span s=
tyle=3D"color:rgb(48,128,128)">(</span>a<span style=3D"color:rgb(48,128,128=
)">.</span>x<span style=3D"color:rgb(48,128,128)">)</span><span style=3D"co=
lor:rgb(48,128,128)">)</span><span style=3D"color:rgb(64,96,128)">;</span>

</pre></div><div><br></div><div>To avoid a valueless result in case of exce=
ption, one&#39;s first thought might be to move first into a temporary:</di=
v><div><br></div><div><pre style=3D"background:rgb(246,248,255);color:rgb(0=
,0,32)">  X temp <span style=3D"color:rgb(64,96,128)">{</span> <span style=
=3D"color:rgb(0,102,238)">std</span><span style=3D"color:rgb(64,96,128)">::=
</span><span style=3D"color:rgb(0,48,96)">move</span><span style=3D"color:r=
gb(48,128,128)">(</span>a<span style=3D"color:rgb(48,128,128)">.</span>x<sp=
an style=3D"color:rgb(48,128,128)">)</span> <span style=3D"color:rgb(64,96,=
128)">}</span><span style=3D"color:rgb(64,96,128)">;</span>
  b<span style=3D"color:rgb(48,128,128)">.</span>y<span style=3D"color:rgb(=
48,128,128)">.</span><span style=3D"color:rgb(48,128,128)">~</span>Y<span s=
tyle=3D"color:rgb(48,128,128)">(</span><span style=3D"color:rgb(48,128,128)=
">)</span><span style=3D"color:rgb(64,96,128)">;</span>
  <span style=3D"color:rgb(32,0,128);font-weight:bold">new</span> <span sty=
le=3D"color:rgb(48,128,128)">(</span><span style=3D"color:rgb(48,128,128)">=
&amp;</span>b<span style=3D"color:rgb(48,128,128)">.</span>x<span style=3D"=
color:rgb(48,128,128)">)</span> X<span style=3D"color:rgb(48,128,128)">(</s=
pan><span style=3D"color:rgb(0,102,238)">std</span><span style=3D"color:rgb=
(64,96,128)">::</span><span style=3D"color:rgb(0,48,96)">move</span><span s=
tyle=3D"color:rgb(48,128,128)">(</span>temp<span style=3D"color:rgb(48,128,=
128)">.</span>x<span style=3D"color:rgb(48,128,128)">)</span><span style=3D=
"color:rgb(64,96,128)">;</span>

</pre></div><div><br></div><div>Unfortunately, this does not gain anything.=
 Now the second move constructor may throw, resulting in the same situation=
..</div><div><br></div><div>However!</div><div><br></div><div>If C++ impleme=
nted relocation, as described in this proposal P0023:</div><div><br></div><=
div><a href=3D"http://denisbider.com/Relocator.pdf" target=3D"_blank" rel=
=3D"nofollow" onmousedown=3D"this.href=3D&#39;http://www.google.com/url?q\x=
3dhttp%3A%2F%2Fdenisbider.com%2FRelocator.pdf\x26sa\x3dD\x26sntz\x3d1\x26us=
g\x3dAFQjCNGRaVpviwtOSXhpXtDNRASkBLXVYw&#39;;return true;" onclick=3D"this.=
href=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fdenisbider.com%2FRe=
locator.pdf\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGRaVpviwtOSXhpXtDNRASkB=
LXVYw&#39;;return true;">http://denisbider.com/<wbr>Relocator.pdf</a></div>=
<div><br></div><div>Then the solution involving a temporary would work:</di=
v><div><br></div><div><pre style=3D"background:rgb(246,248,255);color:rgb(0=
,0,32)">  <span style=3D"color:rgb(0,102,238)">std</span><span style=3D"col=
or:rgb(64,96,128)">::</span>aligned_storage_t<span style=3D"color:rgb(64,96=
,128)">&lt;</span><span style=3D"color:rgb(32,0,128);font-weight:bold">size=
of</span><span style=3D"color:rgb(48,128,128)">(</span><wbr>X<span style=3D=
"color:rgb(48,128,128)">)</span><span style=3D"color:rgb(48,128,128)">,</sp=
an> alignof<span style=3D"color:rgb(48,128,128)">(</span>X<span style=3D"co=
lor:rgb(48,128,128)">)</span><span style=3D"color:rgb(64,96,128)">&gt;</spa=
n> tempData<span style=3D"color:rgb(64,96,128)">;</span>
  X<span style=3D"color:rgb(48,128,128)">*</span> temp <span style=3D"color=
:rgb(48,128,128)">=3D</span> <span style=3D"color:rgb(32,0,128);font-weight=
:bold">new</span> <span style=3D"color:rgb(48,128,128)">(</span>tempData<sp=
an style=3D"color:rgb(48,128,128)">)</span> <span style=3D"color:rgb(64,96,=
128)">{</span> <span style=3D"color:rgb(0,102,238)">std</span><span style=
=3D"color:rgb(64,96,128)">::</span><span style=3D"color:rgb(0,48,96)">move<=
/span><span style=3D"color:rgb(48,128,128)">(</span>a<span style=3D"color:r=
gb(48,128,128)">.</span>x<span style=3D"color:rgb(48,128,128)">)</span> <sp=
an style=3D"color:rgb(64,96,128)">}</span><span style=3D"color:rgb(64,96,12=
8)">;</span>
  b<span style=3D"color:rgb(48,128,128)">.</span>y<span style=3D"color:rgb(=
48,128,128)">.</span><span style=3D"color:rgb(48,128,128)">~</span>Y<span s=
tyle=3D"color:rgb(48,128,128)">(</span><span style=3D"color:rgb(48,128,128)=
">)</span><span style=3D"color:rgb(64,96,128)">;</span>
  <span style=3D"color:rgb(32,0,128);font-weight:bold">new</span> <span sty=
le=3D"color:rgb(48,128,128)">(</span><span style=3D"color:rgb(48,128,128)">=
&amp;</span>b<span style=3D"color:rgb(48,128,128)">.</span>x<span style=3D"=
color:rgb(48,128,128)">)</span> <span style=3D"color:rgb(48,128,128)">&gt;<=
/span><span style=3D"color:rgb(48,128,128)">&gt;</span>X<span style=3D"colo=
r:rgb(48,128,128)">(</span><span style=3D"color:rgb(48,128,128)">*</span>te=
mp<span style=3D"color:rgb(48,128,128)">)</span><span style=3D"color:rgb(64=
,96,128)">;</span>

</pre></div><div><br></div><div>This would now be exception-safe:</div><div=
><br></div><div>- without requiring pilfering;</div><div>- and without a=C2=
=A0potentially, but almost never, valueless variant.</div><div><div><div><d=
iv><br></div><div>Food for thought?</div><div><br></div></div></div></div><=
div>I believe the relocation proposal has so far not progressed for, at lea=
st, these two reasons:</div><div><br></div><div>(1)=C2=A0Proposals require =
champions to travel to meetings=C2=A0to represent them.</div><div>(2)=C2=A0=
I am not willing to travel for this proposal, because I think the C++ commi=
ttee should just do the right thing, independent of who travels to a meetin=
g.</div><div><br></div><div>The language should=C2=A0consider ideas based=
=C2=A0on their merit -=C2=A0not conditional on the appearance of valiant kn=
ights who=C2=A0will cross swamps and deserts, to rescue=C2=A0ideas=C2=A0fro=
m a castle. :-)</div><div><br></div><div><br></div></div></blockquote></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/e9fdc297-6cb0-4b6e-84d3-bc0b04c003a6%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/e9fdc297-6cb0-4b6e-84d3-bc0b04c003a6=
%40isocpp.org</a>.<br />

------=_Part_6221_970988934.1469670256783--

------=_Part_6220_1247268716.1469670256782--

.

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

On 27 July 2016 at 20:44, <demiobenour@gmail.com> wrote:

> Here is another option: require move constructors to be noexcept for use
> in variants.
>

We've been through that argument already.   Multiple times.  It never
gained consensus.
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  +1-847-691-1404

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BOVfW-3R6D%3Dq3VBrFpLCiU8%3DYVgVSRQtCcnxAG6kDWSmw%40mail.gmail.com.

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

<div dir=3D"ltr"><div class=3D"gmail_extra">On 27 July 2016 at 20:44,  <spa=
n dir=3D"ltr">&lt;<a href=3D"mailto:demiobenour@gmail.com" target=3D"_blank=
">demiobenour@gmail.com</a>&gt;</span> wrote:<br><div class=3D"gmail_quote"=
><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1=
px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Here is another option: re=
quire move constructors to be noexcept for use in variants.<div></div></div=
></blockquote></div><br>We&#39;ve been through that argument already. =C2=
=A0 Multiple times.=C2=A0 It never gained consensus.<br>-- <br><div data-sm=
artmail=3D"gmail_signature"><div dir=3D"ltr"><div><div dir=3D"ltr"><div>=C2=
=A0Nevin &quot;:-)&quot; Liber=C2=A0 &lt;mailto:<a href=3D"mailto:nevin@evi=
loverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>&gt; =C2=A0<a hr=
ef=3D"tel:%2B1-847-691-1404" value=3D"+18476911404" target=3D"_blank">+1-84=
7-691-1404</a></div></div></div></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/CAGg_6%2BOVfW-3R6D%3Dq3VBrFpLCiU8%3DY=
VgVSRQtCcnxAG6kDWSmw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BOV=
fW-3R6D%3Dq3VBrFpLCiU8%3DYVgVSRQtCcnxAG6kDWSmw%40mail.gmail.com</a>.<br />

--001a113e9346a7b9ee0538a86506--

.