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.
--
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
