As each function with NRVO must know, when the to-be-returned object is constructed that it is meant for return (because then it is constructed in the return slot from the caller), it is no limitation to fix the return variable for the whole function.     mutex Func(void) {     mutex a;     mutex b;     if (cond)         return a;     else         return b; }   is not possible with NRVO anyway.     Some languages use the name of the function as return variable placeholder. But that name has already meaning in C/C++ to point to the function itself.   A fixed name like _Retvar feels a bit off: One more magic name and only for a technical case. _RetNRVO would perhaps be even worse.   It feels more natural to put the name in the approximately same location as the parameter names. It is a central place. And here names are defined anyway.       BTW a simpler, but (seemingly) less powerful, variant would be one, where the return variable has to be constructed at the beginning of the function:   auto Func(void) -> mutex _Retvar{} { }   Then errors like no construction or double construction are easier to detect and we have no odd construction of an already named entity later in the code.     Seemingly less powerful, because if the constructor parameters are more complicated, it is always possible to delegate.   auto Func(int a) -> mutex _Retvar{Func2(a)} { }     But a hassle for, if Func2a and Func2b actually share code:   auto Func(int a, int b) -> mutex _Retvar{Func2a(a), Func2b(b)} { }           -----Ursprüngliche Nachricht----- Von:Sebastian Wittmeier <wittmeier_at_[hidden]> Gesendet:So 19.05.2024 23:08 Betreff:AW: [std-proposals] std::elide An:std-proposals_at_[hidden]; Is there some syntactic space in trailing return types? Something like       auto Func(void) -> mutex _Retvar   would feel to be the most logical solution.