[Development] Disavowing the Lakos Rule for Q_ASSERT

[Thiago Macieira]

On Monday 26 August 2024 13:12:55 GMT-7 Thiago Macieira wrote:
> "Q_ASSERT don't affect noexceptness"
> 
> Or
> 
> "noexcept(false) if you call other, noexcept(false) functions from your
> code", which includes all the pthread cancellation points in glibc. Since
> qt_assert is noexcept, Q_ASSERT is not included. This is very easy to
> implement with a static checker.
> 
> We could be more complex, with "Q_ASSERT that check preconditions imply
> noexcept(false) but Q_ASSERT that verify the state of the internal invariant
> against corruption don't". This would not be easy to implement with a
> static checker.

I propose we follow the Standard Library implementors' example of 
std::vector::operator[]

libstdc++ does have an assertion there:
      const_reference
      operator[](size_type __n) const _GLIBCXX_NOEXCEPT
      {
            __glibcxx_requires_subscript(__n);
            return *(this->_M_impl._M_start + __n);
      }

So does libc++:
vector<_Tp, _Allocator>::operator[](size_type __n) _NOEXCEPT {
  _LIBCPP_ASSERT_VALID_ELEMENT_ACCESS(__n < size(), "vector[] index out of 
bounds");
  return this->__begin_[__n];
}

Let's call this Pragmatic Lakos Rule.

-- 
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/20240826/aa2c88c5/attachment-0001.bin>