Hi,
Qt's container classes (at least those listed in
https://doc.qt.io/qt-6/containers.html + QCache) reject types with
throwing destructorss via static_assert[1].
There is however one "container" which doesn't reject such types:
QVariant. Even though it's own destructor is noexcept, it doesn't reject
types whose destructor is potentially throwing. My question is: Do we
want to change this, and if so, how? There are at least three alternatives:
1. Don't do anything; that's the behavior we have since at least Qt 5.
If the dtor doesn't actually throw, everything is fine; if it does
throw, we're calling std::terminate. Might lead to unexpected results,
but doing nothing obviously doesn't break any existing code. It is
however inconsistent with other types.
2. Warn, but still accept such types [2]. I've implemented that in
https://codereview.qt-project.org/c/qt/qtbase/+/580560. Anyone one
stores a type with a throwing dtor would get a warning, but everything
still compiles. The warning can however be considered spurious if the
author knows that given their usage, the type would never throw.
3. Reject such types at compile time. That would be consistent with
other types, but might break existing code, even code that works
perfectly fine because it can never actually throw.
I'm leaning towards either 1 (nobody ever reported a bug about QVariant
calling std::terminate so far), or 2 ( more consistent with our policy
for containers, highlights that such usage is potentially dangerous).
I'd welcome any comments on concerns.
Kind regards,
Fabian
[1] There are however still some methods which are marked as
conditionally noexept, like QCache::take, even though that can never be
the case given the static_assert.
[2] At least in cases where we can detect it at compile time; the API
using QMetaType would require storing the necessary information in
QMetaType, and a runtime check.
--
Fabian Kosmale
Manager R&D
The Qt Company GmbH
Erich-Thilo-Str. 10
D-12489 Berlin
fabian.kosm...@qt.io
+49 1638686070
--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
