[Development] Disavowing the Lakos Rule for Q_ASSERT

[Ville Voutilainen]

On Tue, 27 Aug 2024 at 05:21, Thiago Macieira <thiago.macieira at intel.com> wrote:
>
> On Monday 26 August 2024 17:18:22 GMT-7 Ville Voutilainen wrote:
> > So eventually such libraries
> > need to
> > be fixed so that they ship configurations and builds where such
> > functions can be compiled as non-noexcept with contract checks turned
> > on, so that
> > throwing violation handlers can be used. With those (useless)
> > noexcepts there, we have the library that's supposed to be the most
> > generic and the
> > most foundational, and it fails to be that, it bakes in a very
> > particular failure mode for logic errors.
>
> Is there a paper proposing the removal of those noexcepts?

Nothing to remove, the spec doesn't make those functions noexcept.

> And where does it end? Do any pointer dereferences imply a precondition and
> thus not-noexcept?

Yes, they do. But for the time being, a dereference of a raw pointer
is not a contract violation.
And the deference operators for unique_ptr and shared_ptr are
noexcept, so that's a violation
of the Lakos Rule. There are imperfections in this world.