Yes, you are right, it will not fit in current object model, But if we did
assume something about destructors, why we cant assume something about move
constructors? It would be great to define normal C++ type as nothrow
movable and force it, again, im about

Type(Type&& x) = swap; which can be used for many many types in practice,
(it means for compiler, that move constructor == make default and swap,
which is equal to exchange data from X to *this)

e.g. its how std:vector constructor works in typical implementation

It makes code simpler, removes common place for errors (add field - not
change constructor - all breaks), it helps compiler to understand which
type is self reference (~all types with non trivial move constructor are
self reference, if they did not use = swap)

Also, its possible to detect (with this change) if destructor of move-out
state is noop (compiler can prove it by running contsexpr T() + ~T() and
checking if it is rly noop)

This helps replace optimization in loops and makes possible to optimize
things like T x = ..; T y = std::move(x); == just remove move constructor +
destructor and construct 'x' on 'y' place

etc


вт, 28 окт. 2025 г. в 21:53, Sebastian Wittmeier via Std-Proposals <
std-proposals_at_[hidden]>:

> You backup the memory of a non-trivially movable class.
>
>
>
> So you neither call the destructor, nor move constructor nor move operator.
>
>
>
> But the object has a different address and a new object is started to be
> constructed at the old address.
>
>
>
> With it for some amount of time you break all pointers and references to
> this object.
>
>
>
>
>
> You would have to introduce a new property of a type, that there cannot be
> any pointers or references to it and it also has only member variables with
> that property and it inherits from those types only.
>
>
>
> Your idea does not work for arbitrary classes and breaks the foundational
> guarantees an object should get.
>
>
>
> An object might even not know itself that there is a pointer out there, if
> a member variable type creates and communicates the pointer.
>
>
>
> That is a guarantee objects had for decades of C++ code. If you break it,
> it cannot be for arbitrary classes, only for specific ones.
>
>
>
>
>
> -----Ursprüngliche Nachricht-----
> *Von:* Nikl Kelbon via Std-Proposals <std-proposals_at_[hidden]>
> *Gesendet:* Di 28.10.2025 17:13
> *Betreff:* Re: [std-proposals] Way to get rid of valueless_by_exception
> in std::variant
> *An:* std-proposals_at_[hidden];
> *CC:* 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
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>