As far as I understood, 'stores all fields separatelly', the class layout is dissolved, and all member variables are stored individually as local variables.   So the storage for o.value is provided by the caller, the other member variables are stored on the stack (local to the function).   Besides a lot of issues with class encapsulation (and the restrictions for which class types it would be allowed and whether one would want such a feature, even if it would be implementable), it would be really difficult for the member functions of std::optional to find their member variables. They would not be a constant index within the object memory storage, but each member variable would have its individual pointer.   It would not be any longer a single *this pointer. Besides problems with calling the member variables, you would get problems with identity of objects and with storing references and pointers to objects.     -----Ursprüngliche Nachricht----- Von:Jason McKesson via Std-Proposals <std-proposals_at_[hidden]> Gesendet:Mo 21.08.2023 17:09 Betreff:Re: [std-proposals] Copy-construct, move-construct, and PR-construct An:std-proposals_at_[hidden]; CC:Jason McKesson <jmckesson_at_[hidden]>; On Mon, Aug 21, 2023 at 11:04 AM Nikl Kelbon via Std-Proposals <std-proposals_at_[hidden]> wrote: > > Hmm, may this problem be solved by 'inline' structs/ variables? > Like > > inline optional o = foo(); // stores all fields separatelly > return o.value;                // return 'field' which is local value really here, so NRVO possible That's not how NRVO works. It is only permitted in the case of `return <local_variable>;`, not `return <local_variable>.<member>;`. It would be impossible to implement it in the way you're talking about, since it is the caller who provides storage for the return value. And thus, the caller would have to know to provide enough storage for `o`. -- Std-Proposals mailing list Std-Proposals_at_[hidden] https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals