Date: Fri, 27 Dec 2024 12:17:02 +0200
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.
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.
Received on 2024-12-27 10:17:16