[Development] QVariant and types with throwing dtors
Marc Mutz
marc.mutz at qt.io
Tue Aug 27 06:42:26 CEST 2024
On 27.08.24 01:33, Ville Voutilainen wrote:
> On Mon, 26 Aug 2024 at 20:41, Marc Mutz via Development
> <development at qt-project.org> wrote:
>> What is unacceptable in (1) (doing nothing) is not even _informing_
>> users about what we found¹, so _they_ can decide for themselves what to do.
>>
>> ¹ neither at compile-time, nor runtime, nor coding time (static checker)
>> nor at documentation reading time.
>>
>> We want our APIs to be easy to use and hard to abuse. It's easy to abuse
>> QVariant in this way, so it behooves us to try to do _something_ about it.
>
> Considering that types with throwing destructors are rarer than
> unicorns, that doesn't exactly seem
> like something we should put effort into.
I tend to agree. Which is why
static_assert(std::is_nothrow_destructible_v<T>); is the simplest for
us: banning throwing dtors as QVariant payloads (the way we already do
for our other container classes, btw), means we can continue to ignore
the issue, don't need to add more tests, maybe one line of docs copied
from QList, and users are informed, as well.
So I think that's the sweet spot. Users might have to wrap their types
in a wrapper that logs/swallows or otherwise handles the exception from
their type's dtor, or migrate to std::any, but that's SEP.
So why do we want to spend a man week or so on a static checker instead
that 90% of our users will never use, anyway (and neither do we,
considering the number of Clazy violations in Qt that only get fixed now
because they were re-implemented in Axivion)?
Thanks,
Marc
--
Marc Mutz <marc.mutz at qt.io> (he/his)
Principal Software Engineer
The Qt Company
Erich-Thilo-Str. 10 12489
Berlin, Germany
www.qt.io
Geschäftsführer: Mika Pälsi, Juha Varelius, Jouni Lintunen
Sitz der Gesellschaft: Berlin,
Registergericht: Amtsgericht Charlottenburg,
HRB 144331 B
More information about the Development
mailing list