[[nodiscard]] and KDE coding policy

[Volker Krause]

On Donnerstag, 30. Juli 2026 17:14:44 Mitteleuropäische Sommerzeit 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.
> 
> 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?

My approach so far is:
- Add it everywhere where ignoring the return value is definitely an error.
- Don't add it where ignoring the return value is valid, even if unlikely.

That seems roughly in line with the Qt policy.

Practically, clang-tidy as part of the local LSP setup takes care of most most 
of this automatically.

I have so far only added this in new code, or when doing larger work on 
existing code. It's technically source incompatible for -Werror users, but if 
it's only added on definite error cases any compile breakage following from 
that is actually uncovering a real error, so that's fine IMHO.

Cases like QFile::open are the more difficult decision IMHO, not sure we have 
many of those though. I'd say those will always need to be handled case-by-
case during reviews.

I'm not the biggest fan of mass code changes for this, hard to review and not 
worth the risk over the potential gain IMHO.

Regards,
Volker
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 232 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-devel/attachments/20260731/058d59e9/attachment.sig>