On Wed, 21 Dec 2022 at 09:38, Edward Catmur <ecatmur_at_[hidden]> wrote:
>
>
>
> On Wed, 21 Dec 2022 at 08:29, Ville Voutilainen <ville.voutilainen_at_[hidden]> wrote:
>>
>> On Mon, 19 Dec 2022 at 14:51, Sébastien Bini <sebastien.bini_at_[hidden]> wrote:
>> >
>> > On Mon, Dec 19, 2022 at 1:11 PM Ville Voutilainen <ville.voutilainen_at_[hidden]> wrote:
>> >>
>> >> I don't get it. If we have a new kind of constructor, there is no ABI
>> >> _break_, since it's just a new constructor. So why aren't you adding
>> >> such
>> >> a new constructor for pair?
>> >>
>> >> Since this is a semantic facility with semantic guarantees, using
>> >> attributes here seems like the wrong thing to do.
>> >
>> >
>> > I get your confusion. Let me explain in more detail. Let's say you want to call this relocation constructor with a function parameter as source object. This function parameter was passed by value to the function:
>> >
>> > void bar(T);
>> > void foo(T val)
>> > { bar(reloc val); }
>> >
>> > To simplify, the reloc call here will call the relocation constructor for us. When an object is passed to the relocation constructor, its destructor must not be called. So in the example, foo must not call the destructor of val. However, if foo's ABI is caller-destroy, then foo doesn't have the means of doing that, as it is not in charge of calling the destructor of val in the first place.
>>
>> The problem goes away if the semantics of destructive move are such
>> that the destructive-moved-from object is in a state where
>> destruction is valid but not necessary.
>
>
> Yes; we don't want that, since then we would be unable to use relocate-only types such as never-empty types such as not_null<unique_ptr>. For another example, guard types often need to be relocatable, but move support and an empty state add considerable complexity, often more than doubling the amount of code required.

So, rather than have a destructive move where such a semantic
restriction would be in place, do you prefer not having destructive
move at all?