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) 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.
One thing that Marc didn't mention is that we will be independent of the Standard Library's own ability to throw on its precondition violations. We will not count on it nor trust that it works, because it seems some or all of them have painted themselves into a corner that makes throw-on-violation impossible. In turn this means there's no support for throw-on-violations for Qt code in production. Unless things change and that won't happen until the implementations have precondition support, we'll only use this for unit- testing our APIs. And I really mean unit-testing: tst_QList can test its operator[], but tst_QObject shouldn't. I don't think we'll prohibit this. But it will be a gun and there's your foot over there... -- Thiago Macieira - thiago.macieira (AT) intel.com Principal Engineer - Intel DCAI Platform & System Engineering
smime.p7s
Description: S/MIME cryptographic signature
-- Development mailing list [email protected] https://lists.qt-project.org/listinfo/development
