Re: [[nodiscard]] and KDE coding policy

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.

I could also argue that excessive [[nodiscard]] will worsen code 
readability and C++ is already a too verbose language, e.g. constexpr 
int foo() const noexcept.

I think that if somebody wants the compiler to print an angry warning 
about stray getters, there should be a special warning in the compiler. 
[[nodiscard]] doesn't seem like the suitable measure to achieve that. 
IMHO it should be reserved for very very important return values that 
you must never ignore, stray getter calls are just not them.

Regards,
Vlad

> I've seen everyone has their own set of rules:
>   - some don't use it
>   - some add it when the return value is important (like opening a file
> having an error)
>   or when the return value has a RAII pattern or requires the caller to
> take over memory ownership
>   - some add it to every getter
>
> I don't like inconsistency and I don't like repeated discussions on
> merge requests.
>
> I would like to as a group decide on something and add it to
> https://community.kde.org/Policies/Library_Code_Policy at least for
> new code with a definitive rule that everyone has to follow.
>
> Whether we change existing code is also up for discussion it's a
> source-incompatible change even though it's binary compatible. We
> normally avoid source compatible changes, but it shouldn't make too
> much difference unless we're exposing existing mistakes - which is
> something we want to do.
>
> Any thoughts?
>
> David