I admit that its observable behavior and can change behavior for such
types, but on other side i want C++ standard and library to define what
exactly copy and move must do. As it had done for destructors.

Its useful for optimizations, it can simplify language, etc etc

Its was earlier in my proposal about

Type(Type&&) = swap;
Type& operator(Type&&) = swap;


вт, 28 окт. 2025 г. в 21:13, Nikl Kelbon <kelbonage_at_[hidden]>:

> *programmer
>
> вт, 28 окт. 2025 г. в 21:13, Nikl Kelbon <kelbonage_at_[hidden]>:
>
>> I dont see this as counter example. Its example of type, where move
>> constructor does not guarantee... Any guarantees. So, its just correct
>> behavior, where
>>
>> 1. variant not changed (still A)
>> 2. B tried to construct and throws exception
>>
>> I think compiler who writes such beaty code must expect exactly such
>> behavior
>>
>> вт, 28 окт. 2025 г. в 20:58, Jonathan Wakely via Std-Proposals <
>> std-proposals_at_[hidden]>:
>>
>>>
>>>
>>> On Tue, 28 Oct 2025 at 15:04, Pavel Vazharov via Std-Proposals <
>>> std-proposals_at_[hidden]> wrote:
>>>
>>>> On Tue, Oct 28, 2025 at 4:46 PM Nikl Kelbon via Std-Proposals <
>>>> std-proposals_at_[hidden]> wrote:
>>>> >
>>>> > Thanks for the links, but I don't see any discussion of this
>>>> particular idea there. Instead, they're discussing allocating the value on
>>>> the heap or doubling the buffer.0308
>>>> The first sentence in the https://wg21.link/P0308 says
>>>> This paper argues in section III that when variant's contained types
>>>> have noexcept move constructors, variant *shall* *never* be valueless,
>>>> that is, the specification should *statically* guarantee that
>>>> valueless_by_exception() will *never* return true.
>>>>
>>>>
>>> Ah yes, but you see that paper didn't discuss the possibility of "just
>>> make it work for all types by using magic" ;-)
>>>
>>>
>>> --
>>> Std-Proposals mailing list
>>> Std-Proposals_at_[hidden]
>>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>>
>>