I'm ok with 1-3, I'm not ok with 4. The state of the art is what the std prescribes, not what a stdlib implementation does. stdlibs are magic; they can theoretically remove the noexcept for new code and keep it for old. Or they can let contract violations pass magically. We can't, at least not with a lot of manual labour (QT_REMOVED_SINCE/QT6_NEW_OVERLOAD).
If we get (1), I think we'll very quickly also get a build mode in which these throw. And I'm also questioning the alternatives to throwing from assertions (or Q_PRE, if you want). You can fork, yes. Very complicated, and probably slow as hell (I still remember Qt 5 QSharedPointer negative tests were even slow on Linux). We can't call a QtTest-handler, because that handler cannot return without an exception, because the code following the assertion typically assumes that the assertion holds and runs into Language UB (non-recoverable) as a consequence if it didn't. Finally, one thing that Lakos wrote in his paper (https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2861r0.pdf) was that it should be up to *the owner of main()* to determine how precondition violations are handled. Neither std nor Qt should decide for the user here. I think this is very pertinent to the current software security legislation being proposed on both sides and Qt should not shut the door in front of users that would like to run checked build modes in production. Therefore: no noexcept on narrow-contract functions is still paramount, IMNSHO. Again, a hunch is not enough to sway me here. A meaningful increase in runtime speed would need to be demonstrated, and even then, we would need to weigh that feature against the desire for certain customers (one being ourselves, for negative testing) to use a checked build mode in production. Thanks, Marc On 28.08.24 17:49, Thiago Macieira wrote: > On Wednesday 28 August 2024 03:23:52 GMT-7 Volker Hilsheimer via Development > wrote: >> TL;DR: Given that the tradeoff is between two marginally and somewhat >> speculative benefits, it seems to me that a pragmatic (as opposed to >> dogmatic) application of the Lakos rule in the cases where Q_ASSERT is used >> to verify preconditions is sensible for us. Which in our governance model >> translates to maintainer privilege. In other words: if Thiago believes that >> making something noexcept is correct because a try/catch on the call site >> would be the completely wrong tool to deal with the mistake that the >> Q_ASSERT guards against, then that’s acceptable (and doesn’t mean that it >> cannot be discussed passionately in code review). > > Here's the summary if what I am proposing: > > 1. Introduce new macros to document pre- and post-conditions, to be used > mostly in inline code. > > Eventually, those pre- and post-conditions can be changed into contracts, when > the language has them and we can use them in our sources without lots of ugly > #if. Depending on the syntax for them (which I didn't bother to look up), that > may not be until 2032 for the majority of contracts. > > 2. Leave Q_ASSERT for checking on internal conditions, which the user has no > reasonable way of corrupting, short of messy bugs elsewhere. > > I mean, even this function has a precondition of "you haven't overwritten > global memory somehow": > Q_DECL_IMPORT extern int value; > int f() { return value; } > > 3. Internal consistency checks do not imply narrow contract. Therefore, > Q_ASSERTs do not imply noexcept(false) > > 4. [This is the contentious one, if we accept #1] Functions with precondition > checks and narrow contracts can still be noexcept > > In this, I am proposing we follow the state-of-the-art, namely the Standard > Libraries, where they have marked noexcept functions with certain > preconditions like std::vector::operator[] and std::basic_string_view char+len > constructor. > > IF and when they deploy a solution to allow turning those checks into checked > preconditions that may throw, we copy their solution and apply the same. > > -- 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
