Den fre 6 sep. 2024 16:16Marc Mutz via Development < [email protected]> 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 <[email protected]> (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 > [email protected] > https://lists.qt-project.org/listinfo/development >
-- Development mailing list [email protected] https://lists.qt-project.org/listinfo/development
