On Monday 26 August 2024 22:53:18 GMT-7 Marc Mutz via Development wrote: > If we make the distinction between Q_ASSERT-as-precondition-check and > Q_ASSERT-as-internal-invariant/state-check (with a new macro > name/names), then I can agree to that. Note, however, that the example > that sparked this discussion (View::slice(int, int)) remains > noexcept(false) under this rule, too. Ditto op==(It, It). > > I have tried to adjust > https://wiki.qt.io/Things_To_Look_Out_For_In_Reviews#noexcept > accordingly. For offline reader convenience, it currently reads:
I still want to go further, with std::vector::operator[] as our example. If it's acceptable for them to use an assertion-in-noexcept in there, then it is for us, even if you and Ville consider it a mistake. The point is that this putative mistake has no consequences, today. It remains to be seen whether it will with contracts, when those come. When contracts come, if those noexcept are a problem, then both libc++ and libstdc++ will deploy a solution, which should suffice for us too. Until then, I don't see a reason to deprive ourselves of any potential benefits that the noexcept might bring. -- Thiago Macieira - thiago.macieira (AT) intel.com Principal Engineer - Intel DCAI Platform & System Engineering
smime.p7s
Description: S/MIME cryptographic signature
-- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
