Date: Sat, 28 Dec 2024 00:52:14 +0000
Haha, I have imagined something called relocating destructor. It looks like `reloc ~T(int)`(the actually return type is T), and will be called like `new(dstptr)T(srcptr->~T(0))`.
获取Outlook for Android<https://aka.ms/AAb9ysg>
________________________________
From: Std-Proposals <std-proposals-bounces_at_[hidden]> on behalf of Oskars Putans via Std-Proposals <std-proposals_at_[hidden]>
Sent: Friday, December 27, 2024 6:17:02 PM
To: std-proposals_at_[hidden] <std-proposals_at_[hidden]>
Cc: Oskars Putans <o.putaans_at_[hidden]>
Subject: [std-proposals] A prvalue constructor/destructor
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.
获取Outlook for Android<https://aka.ms/AAb9ysg>
________________________________
From: Std-Proposals <std-proposals-bounces_at_[hidden]> on behalf of Oskars Putans via Std-Proposals <std-proposals_at_[hidden]>
Sent: Friday, December 27, 2024 6:17:02 PM
To: std-proposals_at_[hidden] <std-proposals_at_[hidden]>
Cc: Oskars Putans <o.putaans_at_[hidden]>
Subject: [std-proposals] A prvalue constructor/destructor
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.
Received on 2024-12-28 00:52:20