> On 16 Jun 2023, at 20:25, Thiago Macieira <thiago.macie...@intel.com> wrote:
>
> On Friday, 16 June 2023 11:05:30 PDT Giuseppe D'Angelo via Development wrote:
>> On 16/06/2023 18:00, Thiago Macieira wrote:
>>> On Friday, 16 June 2023 01:06:33 PDT Stephen Kelly wrote:
>>>> Make sure you're not hitting
>>>>
>>>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96117
>>>
>>> We are indeed hitting that. But there's nothing we can currently do about
>>> it.
>> Why can't we turn Q_DECL_EXPORT to [[gnu::visibility("default")]] to
>> work around the bug?
>
> Marc to comment, but I don't think it solves the MSVC problem we're also
> hitting, which means that adding no_discard to classes is still a problem.
> Therefore, there's no point in changing our Q_DECL_EXPORT.
>
> We'd also need to change *all* our __attributes__, not just the visibility
> ones, and we still risk breaking users' code that have __attributes__ in
> their
> classes and especially functions but use Q_DECL_EXPORT.
>
> Think of declarations like:
>
> [[nodiscard]] Q_CORE_EXPORT Q_DECL_PURE_FUNCTION qsizetype qustrlen(const
> char16_t *str) noexcept;
My take-away is: What we should care about is the small set of RAII classes
where the side-effects of the constructor and destructor are the whole point.
E.g. it would be good if we can reliably encourage a compiler warning for
Listing 1:
QMutexLocker(&mutex);
because that mistake is easily made and positively harmful.
From what I get out of this recap of the state of standard and compilers, it
seems that we can't: class-level [[nodiscard]] doesn’t give us that warning
(reliably, on all compilers), while it does give us warnings that we might not
want (ie when not using the return value of a function). And it’s problematic
to use with whole-sale exported classes; but since RAII types like QMutexLocker
shouldn’t be exported whole-sale anyway, that’s perhaps not a problem in
practice.
So, agree with Marc’s proposal to drop (or at least not add any new) usage of
class-level [[nodiscard]], and to use constructor-level [[nodiscard]] instead
via Q_NODISCARD_CTOR (*). This still makes it a good service to Qt users that
are on C++ 20. For everyone else, things are as they were before.
For all other types, I think it’s quite alright that users writing code as per
Marc's Listings 2-4:
QSize(12, 32);
have to figure out the “hard" way why there is no variable to pass into the
function that they were planning on calling.
Volker
(*) That macro that does nothing until C++20 anyway, so I’d also add the
support for the optional string-literal that C++20 also introduces..
--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
