-----Ursprüngliche Nachricht----- Von:Thiago Macieira via Std-Proposals <std-proposals_at_[hidden]> Gesendet:Do 11.07.2024 16:03 Betreff:Re: [std-proposals] Stop gap required for NRVO until Anton‘s paper is assimilated An:std-proposals_at_[hidden]; CC:Thiago Macieira <thiago_at_[hidden]>; On Thursday 11 July 2024 06:54:03 GMT-7 Frederick Virchanza Gotham via Std- Proposals wrote: > On Thu, Jul 11, 2024 at 2:42 PM Thiago Macieira wrote > > > If we can't get one into the C++26 standard in time, why would we get > > something else in the same line in time? Especially if there's already a > > paper that ostensibly is a better and wider solution? > > The superior paper is suffering a lack of progress. Not enough talk > about it, not enough enthusiasm and drive to pull it into the > Standard. > > My inferior paper is much much much simpler and doesn't require a > change to the core language. Not much thinking required to get it into > the Standard. So if the car brakes don't work, we ask the mechanic to fix the horn?  On first read, I was thinking the horn has a totally different purpose, whereas the proposals solve the same problems. Considering it a bit more, you meant, the horn would warn the passers-by, as the brakes are not working.  The latest draft of Anton's P2025 is here: https://raw.githack.com/Anton3/cpp-proposals/master/draft/d2025r3.html https://github.com/cplusplus/papers/issues/756  There are a lot of issues with the P2025 proposal. Anton summarized them here: https://gist.github.com/Anton3/94142f9783bf4c938aa8dcda2c561305   The last poll was:    We are interested in pursuing work on guaranteed copy elision for named return objects. SF F N A SA 8 12 2 0 0   Send D2025r3 as-is to EWG electronic polling, with the intent of forwarding it to Core for C++23. SF F N A SA 0 0 0 8 10   I believe most or probably all of the 20 examples in D/P2025r3 can be solved with the two new standard functions without any of the 5 issues.  Best, Sebastian  > It's a lot more likely that a simple paper will make it into C++26, > than a much much much more complicated paper. The problem is that there is a better paper in the pipeline. Either it's withdrawn or explicitly rejected, because until then I don't see a path to adding a short-term, stop-gap solution. It's not like we have a pressing need: C++ has existed for 30 years without this, so we can wait a few more years to get the right solution. Either that, or your paper argues that it's a replacement for the sufficiently many use-cases that it makes the other one unnecessary. IMHO Anton's paper gets unnecessary. The compiler vendors/implementers would be free anyway (even according to current rules IIUC) to apply non-mandatory RVO in those cases for optimization purposes for copyable types. Otherwise an explicit call could be preferred in the code anyhow.   That's different from when we added things when we didn't know better, like std::is_constant_evaluated() vs if consteval. Experience can tell us that what we thought was a solution wasn't, or not completely. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org  Principal Engineer - Intel DCAI Platform & System Engineering -- Std-Proposals mailing list Std-Proposals_at_[hidden] https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals