[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