Another destructive move proposal.

The problem with this space has /never/ been syntax. It's been that
variables that have been destructively moved-from continue to exist by name
in the enclosing scope - and the fact that you can destructively move from
a mutable reference in a called function is a footgun for the actual owner
of the object which will still call the constructor.

Basically, it's the rest of the language, not the object being moved.

On Fri, Dec 27, 2024 at 10:17 AM Oskars Putans via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> Inspired by P2785, I propose an alternative of conveying a destructive
> move via something akin to a move destructor.
> I imagine the move destructor to have a signature something akin to
> `~T(T&)` or `~T(T*)`. In this case the passed reference or pointer would
> contain/point to an uninitialized variable. I do dislike it being
> a reference in this way however and prefer the pointer option. It conveys
> the purpose a bit better.
> There would be no collisions with existing implementations as something
> like this would not compile in current versions.
> Its primary purpose would be to transfer any useful data to the passed
> object, destructing any leftovers from the transition.
> It would only be called upon a prvalue assignment or prvalue construction.
> I don't know how feasible it is to implement in this way and what hurdles
> would be ahead for implementers.
> An alternative would be to make T(T) be a valid constructor, but this
> makes a constructor do destructing and I'm not very keen on the idea.
> This would serve as an optional optimization when handling prvalues
> specifically.
>
> Right now you can do something similar with an extra boolean indicating a
> destructed state indicating no destruction necessary to the destructor and
> a constructor that accepts a universal reference constrained to where the
> passed type is the prvalue. This also requires that you cannot implicitly
> copy the value.
>
> something like
> template<typename U>
> T(U&&) requires(std::is_same_v<T, U>)
> This is pretty much the same as T(T) only ugly and going around the
> explicit constraints of the language, prone to memory errors by those who
> don't understand the consequences of this statement.
>
> At the end of the day, should something like this be accepted, it would
> open the door for P2785 or other proposals focusing on relocation to be
> easier to integrate.
>
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>