[[nodiscard]] and KDE coding policy

[Vlad Zahorodnii]

Hi,

On 7/30/26 10:18 PM, jackhill3103 at gmail.com wrote:
> Hi,
>
> On Thursday, 30 July 2026 17:25:24 British Summer Time Vlad Zahorodnii wrote:
>> Hi,
>>
>> On 7/30/26 6:14 PM, David Edmundson wrote:
>>> I'm seeing more and more merge requests using [[nodiscard]] and now
>>> review comments insisting on others adding [[nodiscard]] to new code.
>> My understanding is that [[nodiscard]] is meant for cases where you must
>> really check the return value of a given function.
>>
>> Slapping [[nodiscard]] on every function doesn't seem feasible in long
>> run for the simple reason that it increases the amount of work that
>> developers need to do and developers don't like extra work. It won't be
>> surprising if some forget to add [[nodiscard]]. I already notice this
>> with other minor things like the override keyword for destructors or
>> even the const keyword.
> There are clang-tidy checks misc-const-correctness, modernize-use-override and modernize-use-nodiscard that can be run prior to making a commit. modernize-use-nodiscard only handles const member functions so non-const functions like `open` will require manual review.

Yes, clang-tidy has some checks, but we normally don't run them locally. 
Maybe some checks can run in CI. Although, in case of kwin, I'm very 
worried about increasing CI time even more.

That being said, I still don't think that adding [[nodiscard]] to 
functions such as getters is a good idea. It makes code more verbose, 
with more boilerplate, with little (imho) benefit. Stray getter calls 
are odd but the effort to avoid them is hard to justify.

There should just be a compiler warning about such things (and also a 
way to make specifically [[nodiscard]] warnings fatal).

Regards,
Vlad