mizvekov added a comment. In D104500#2866079 <https://reviews.llvm.org/D104500#2866079>, @rsmith wrote:
> I wonder if we can restore the extension behavior for the types that want it, > while still using the C++98 rules for the rest of the cases? Perhaps we could > use the new C++11-to-C++20 logic even in C++98 if the return type declares a > move constructor? Well if we want to keep supporting it, then my plan would be: It comes back, but it's not exactly the same "C++98 implicit moves" that you used to know, it now has a few cybernetic enhancements: - As far as the rules of what id-expressions are considered move eligible, we keep the same ones as C++20 has. The old one used to apply only to the subset where we can do copy elision. - We jerry rig the first overload resolution, by iterating the construction steps and aborting it in case we pick a constructor or conversion operator which does not take an rvalue reference. I think this way would be a balance where we don't add back too much code, but at the same time we keep compatibility with pure C++98 programs. I think this is in line with the idea of best effort. Though if I may suggest, if we ever hope to sunset C++98, then to stop providing these C++11 extensions would be a good first step... Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D104500/new/ https://reviews.llvm.org/D104500 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
