[Development] Disavowing the Lakos Rule for Q_ASSERT

[Thiago Macieira]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5152 bytes
Desc: not available
URL: <http://lists.qt-project.org/pipermail/development/attachments/20240828/2c5962b6/attachment.bin>