On Saturday 7 September 2024 18:31:27 CEST Marc Mutz via Development wrote:
> Another thing I neglected to mention is that there are two distinct
> steps here. The first is to change certain Q_ASSERT()s into Q_PRE()
> (say) precondition checks that optionally throw on violation. This has
> nothing
Hi,
I don't see how
On 06.09.24 22:34, Thiago Macieira wrote:
[...]
> In turn this means there's no support for throw-on-violations for Qt code in
> production.
[...]
necessarily follows, at least as long as we speak about a Qt-proprietary
mechanism.
Another thing I neglected to mention is tha
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
