Hi, I don't see how
On 06.09.24 22:34, Thiago Macieira wrote: [...] > In turn this means there's no support for throw-on-violations for Qt code in > production. [...] necessarily follows, at least as long as we speak about a Qt-proprietary mechanism. Another thing I neglected to mention is that there are two distinct steps here. The first is to change certain Q_ASSERT()s into Q_PRE() (say) precondition checks that optionally throw on violation. This has nothing to do with C++26/29 contacts. The second step would be to piggy-back on the std contracts work. That realistically is out quite a few years for us, and likely will require a different syntax (placed on the function's declaration instead of into its implementation). So this is not what we need to factor in for Qt 6. But I do note that it should be possible, if cumbersome, to support functions overloaded on nexcept/non-noexcept for a binary-compatible switch between the different build modes (e.g. by template <bool Throw = <build-dependent> R func() noexcept(!Throw); Or using a mechanism similar to REMOVED_SINCE (which is also a way to remove noexcept that we have incorrectly added)). Thanks, Marc -- Marc Mutz <marc.m...@qt.io> (he/his) Principal Software Engineer The Qt Company Erich-Thilo-Str. 10 12489 Berlin, Germany www.qt.io Geschäftsführer: Mika Pälsi, Juha Varelius, Jouni Lintunen Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
