On Wednesday, 8 November 2023 10:05:38 PST Ivan Solovev via Development wrote: > > I think it's acceptable for us to change the return type of a function so > > long as it's getting a new mangling. > > Well, it would be easily achievable for the template methods, but not for > the inline hidden friend helper methods. > As immediate solution that comes to my mind is to add a third argument to > these methods when compiled in C++20 mode. And we could probably use > yet another macro for that. But this will just overcomplicate the things, so > I'm not a big fan of this idea.
Neither am I. If we do this, the third, dummy, disambiguating parameter should simply be the return type itself. It's the clearest solution and makes macro definition simpler. > So, you say that the compiler is smart enough to optimize away conversions > like `std::strong_ordering -> QStrongOrdering -> std::strong_ordering` > because the underlying integral values are the same? Yes. Since everything is idempotent, it should just do nothing. In practice, it looks like one of the conversions is getting clamped: https://gcc.godbolt.org/z/n7ohc9Wo4 It might be possible to massage the code in such a way that the compiler realises that it is always idempotent. I haven't managed yet. We can also just be evil and use bit_cast: https://gcc.godbolt.org/z/e5zefKevP -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering
smime.p7s
Description: S/MIME cryptographic signature
-- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
