On Friday 6 September 2024 16:15:13 CEST Marc Mutz via Development wrote:
> 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) un
Den fre 6 sep. 2024 16:16Marc Mutz via Development <
development@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 demons
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 th
