On Mon, 26 Aug 2024 at 08:26, Marc Mutz via Development <development@qt-project.org> wrote: > My vote goes to (3). (2) is a good intermediate step (e.g. for Qt 6, > with Qt 7 converting to static_assert()). Remember that ctors are > implicitly noexcept in C++, so you need to do actual work to make a type > that's not nothrow_destructible. In Qt, incl. 3rd-party monster > chromium, we have _two_ such types, QChildProcess and > QScopedPropertyUpdateGroup. QtC has another two, in sqlite: > ~AbstractThrowingSessionTransaction and ~AbstractThrowingTransaction. > > So, by an educated guesstimation, this won't be an issue, and possibly > catch mistakes, like when using a 3rd-party library type in QVariant. > > The other option (4) is to make it supported: have a > QVariant::destroy<T>() function that's conditionally noexcept, so users > can destroy the payload in a controlled environment instead of running > into std::terminate() in ~QVariant() (throwing from a noexcept function > will _not_ unroll the stack, so you might not even get logging that you > expected). > > IMHO, (1) is not an acceptable option. Us C++ professionals having identified > this problem after years of it lying dormant, it behooves us, at the > very least, to educate our users about this, e.g. by adding docs, and > maybe a qWarning() in ~QVariant(), if we don't do (2).
If it's not an issue, why is (1) unacceptable? -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
