[Development] Disavowing the Lakos Rule for Q_ASSERT

[Ville Voutilainen]

On Thu, 29 Aug 2024 at 18:34, Thiago Macieira <thiago.macieira at intel.com> wrote:
>
> On Thursday 29 August 2024 06:43:58 GMT-7 Marc Mutz via Development wrote:
> > 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).
>
> They're not _that_ magic. There is a certain amount of compiler-helped magic
> in them, true, but the majority of the Standard Libraries are simply libraries
> written in standard C++. So whatever solution they come up with, even if not
> part of the standard, may be something we can use too. If they decide for a
> binary- or source-incompatible build mode, we can too. If they decide for some
> attribute marker, we can too.

It's very unlikely to be anything other than an incompatible build.
There are very good reasons not
to have some extension or whatever facility that throws through a
noexcept of a function declaration,
even for contract checks performed on the caller-client side. So it's
extremely unlike that any
"yes it's noexcept but throw from it anyway" facility will see the
light of the day.

So, if you wish to add more noexcepts into our code where we don't
demonstrably desperately need them,
and those noexcepts are on narrow-contract functions, at least add
them with a macro.

That doesn't close the door for a relatively simple custom Qt build
where those noexcepts are taken away, and
exceptions can be used for contract violations, at least for Qt code
called by the user, not by Qt itself.