My proposal isn't meant to solve these issues. It is merely a step in that
direction. What i'm proposing is an optional specialization for handling
prvalues in a way that doesn't require the moved from value to be in a
valid state.

On Fri, 27 Dec 2024, 12:19 Gašper Ažman, <gasper.azman_at_[hidden]> wrote:

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