[Development] C++20 ctor-level [[nodiscard]] (was: Re: C++20 @ Qt)

[Ivan Solovev]

> (*)  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..

Our tests actually show that this macro provides an expected warning on most of the compilers that we use in the CI, even in C++17 mode.
IIRC, in my tests I only had issues with INTEGRITY, GCC 9.3.1 on OpenSuse 15.4, and QCC 8.3.0 on QNX.
For these platforms the macro currently does nothing.

Best regards,
Ivan

------------------------------

Ivan Solovev
Senior Software Engineer

The Qt Company GmbH
Erich-Thilo-Str. 10
12489 Berlin, Germany
ivan.solovev at qt.io
www.qt.io

Geschäftsführer: Mika Pälsi,
Juha Varelius, Jouni Lintunen
Sitz der Gesellschaft: Berlin,
Registergericht: Amtsgericht
Charlottenburg, HRB 144331 B
________________________________
From: Development <development-bounces at qt-project.org> on behalf of Volker Hilsheimer via Development <development at qt-project.org>
Sent: Sunday, June 18, 2023 2:59 PM
To: Macieira, Thiago <thiago.macieira at intel.com>; development at qt-project.org <development at qt-project.org>
Subject: Re: [Development] C++20 ctor-level [[nodiscard]] (was: Re: C++20 @ Qt)

> On 16 Jun 2023, at 20:25, Thiago Macieira <thiago.macieira at 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 at qt-project.org
https://lists.qt-project.org/listinfo/development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20230619/6693a36e/attachment-0001.htm>