What do we assume about destructors?   > It would be great to define normal C++ type as nothrow movable and force it The new trivial relocation and relocation feature will help with narrowing the requirements of many types and enable more automatic optimizations and optimizations by the standard and custom libraries.   Probably more types are nothrow relocatable than nothrow movable. (e.g. the probability is smaller that new heap memory is allocated).   But there will continue to be types, which are not nothrow movable.   > [= swap] means for compiler, that move constructor == make default and swap, which is equal to exchange data from X to *this In a general class, even swap is done in a certain order. If a default order is enough, swap can just be called for each sub-object in the order of declaration.   > ~all types with non trivial move constructor are self reference, if they did not use = swap Self-reference is only one possible reason, references by other objects are even more critical, e.g. in multi-threading. Or buffers for DMA or hardware communication.   If you have only self-reference, at least it would provide guarantees that the pointer is not accessed as long as no member functions of the object are called. The object could also be easily rewritten to use the base pointer and an offset. That is really the least of the issues here. However it is prominent, because of SSO in std::string and a nice example.     -----Ursprüngliche Nachricht----- Von:Nikl Kelbon <kelbonage_at_[hidden]> Gesendet:Di 28.10.2025 18:57 Betreff:Re: [std-proposals] Way to get rid of valueless_by_exception in std::variant An:std-proposals_at_[hidden]; CC:Sebastian Wittmeier <wittmeier_at_[hidden]>; Jonathan Wakely <cxx_at_[hidden]>; 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] <mailto: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] <mailto: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] <mailto:std-proposals_at_[hidden]> ; CC:Nikl Kelbon <kelbonage_at_[hidden] <mailto: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] <mailto:std-proposals_at_[hidden]> >:   On Tue, 28 Oct 2025 at 15:04, Pavel Vazharov via Std-Proposals <std-proposals_at_[hidden] <mailto:std-proposals_at_[hidden]> > wrote: On Tue, Oct 28, 2025 at 4:46 PM Nikl Kelbon via Std-Proposals <std-proposals_at_[hidden] <mailto: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] <mailto:Std-Proposals_at_[hidden]> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals -- Std-Proposals mailing list Std-Proposals_at_[hidden] <mailto:Std-Proposals_at_[hidden]> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals -- Std-Proposals mailing list Std-Proposals_at_[hidden] <mailto:Std-Proposals_at_[hidden]> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals