[Development] Compromise: Modified Lakos Rule (was: Re: Disavowing the Lakos Rule for Q_ASSERT)

[Elvis Stansvik]

Den fre 6 sep. 2024 16:16Marc Mutz via Development <
development at qt-project.org> skrev:

> Hi,
>
> Over lunch at QtCS, Thiago and I have reached common ground on this.
>
> Seeding the proposal:
>
> We continue to follow the Lakos Rule, but if slapping noexcept on a
> narrow-contract function demonstrably improves "things" (performance,
> code size?) significantly, then you MAY slap a noexcept on the function,
> provided it's hidden behind a macro. This should be an exception (no pun
> intended): not more than a dozen or so per year.
>
> We have Q_DECL_NOTHROW and Q_DECL_NOEXCEPT that we could repurpose for
> this, but since we maintain these for backwards compatibility, we
> probably don't want do that and change the existing meaning (always
> noexcept) under existing users.
>
> So realistically, we'd need a new macro.
>
> We also seem to agree on the desire to make precondition checks use a
> macro other than Q_ASSERT, and also on having that optionally throw, and
> use it in negative testing.
>
> Details still open:
> - name of the macros
> - default (empty or noexcept; depending on debug/release?,
> developer-build?)
>    - determines what we can do with per-existing noexcept's that violate
>      the Lakos Rule
> - anything I might have forgotten
>
> Discuss :)
>

Arguments always benefit from some food in the bellies :)


> Thanks,
> Marc
>
>
> On 26.08.24 19:56, Thiago Macieira wrote:
> > The Lakos Rule says that methods that only methods with wide contracts
> should
> > be noexcept. That is, if your method has a precondition, it should not be
> > noexcept.
> >
> > This is apparently predicated on the fact that the preconditions will be
> > implementable as C++ contracts some time in the future and that some
> compilers
> > or compilation modes may turn contract verifications into runtime checks.
> > Moreover, said checks can be implemented by throwing an exception
> indicating a
> > contract violation. Alternatively, an application could replace the Qt
> > assertion handler with one that throws (which is currently not possible
> > because qt_assert is noexcept, therefore this replacement is not
> supported).
> >
> > I'd like to request Qt code not obey that rule. In my opinion, it's a
> defect
> > in the contract implementation rather than on Qt code. The *pre*
> condition
> > indicates something that must be true before the method is called and
> > therefore the method's own noexcept specification does not apply *yet*.
> >
> >
> --
> Marc Mutz <marc.mutz at qt.io> (he/his)
> Principal Software Engineer
>
> The Qt Company
> Erich-Thilo-Str. 10 12489
> Berlin, Germany
> www.qt.io
>
> Geschäftsführer: Mika Pälsi, Juha Varelius, Jouni Lintunen
> Sitz der Gesellschaft: Berlin,
> Registergericht: Amtsgericht Charlottenburg,
> HRB 144331 B
>
> --
> Development mailing list
> Development at qt-project.org
> https://lists.qt-project.org/listinfo/development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20240906/2b55638e/attachment-0001.htm>