On 27.08.24 01:33, Ville Voutilainen wrote: > On Mon, 26 Aug 2024 at 20:41, Marc Mutz via Development > <[email protected]> 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 <[email protected]> (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 -- Development mailing list [email protected] https://lists.qt-project.org/listinfo/development
