On 19.06.23 09:55, Ivan Solovev via Development wrote: > > (*) 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. Right. P1771 encourages to retroactively apply [[nodiscard]] on ctors to C++17. It seems only GCC misinterpreted the C++17 wording as not applying to ctors. So it's really not a C++20 feature, but more like a [[nodiscard]] bugfix. Thankfully, the feature test macro value was updated, so we have an easy check for the presence of the bugfix.
> > I’d also add the support for the optional string-literal that C++20 > > also introduces.. That _is_ a new feature. I have written in the corresponding Jira epic¹ that I don't see a strong use-case for [[nodicard("reason")]]. Expanding on that: there's just one action if you get the warning: _use_ the value. It's not like [[deprecated("alternative")]] where the string provides essential information (what to do instead). So I've suggested to no supply a Q_NODISCARD_X/Q_REQUIRED_RESULT_X, as we've just replaced Q_REQUIRED_RESULT with [[nodiscard]] across the code-base. It's easily supplied if someone comes up with a use-case, though. ¹ https://bugreports.qt.io/browse/QTBUG-104134 Thanks, Marc -- Marc Mutz <marc.m...@qt.io> 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 Development@qt-project.org https://lists.qt-project.org/listinfo/development