Re: [[nodiscard]] and KDE coding policy

--nextPartQfeYe_4WRgCMkavsQJuD8A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="utf-8"; protected-headers="v1"
From: Volker Krause <[email protected]>
To: kde-devel <[email protected]>
Subject: Re: [[nodiscard]] and KDE coding policy
Date: Fri, 31 Jul 2026 17:50:21 +0200
Message-ID: <[email protected]>
Organization: KDE
In-Reply-To:  <CAGeFrHB4Ovudh1Tf-D6q=tar3E-h7f_2tu_9Q+JeoHb3qJZC9w@mail.gmail.com>
References:  <CAGeFrHB4Ovudh1Tf-D6q=tar3E-h7f_2tu_9Q+JeoHb3qJZC9w@mail.gmail.com>
MIME-Version: 1.0

On Donnerstag, 30. Juli 2026 17:14:44 Mitteleurop=C3=A4ische Sommerzeit Dav=
id=20
Edmundson wrote:
> I'm seeing more and more merge requests using [[nodiscard]] and now
> review comments insisting on others adding [[nodiscard]] to new code.
>=20
> 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
>=20
> I don't like inconsistency and I don't like repeated discussions on
> merge requests.
>=20
> 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.
>=20
> 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.
>=20
> Any thoughts?

My approach so far is:
=2D Add it everywhere where ignoring the return value is definitely an erro=
r.
=2D 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 m=
ost=20
of this automatically.

I have so far only added this in new code, or when doing larger work on=20
existing code. It's technically source incompatible for -Werror users, but =
if=20
it's only added on definite error cases any compile breakage following from=
=20
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 ha=
ve=20
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 n=
ot=20
worth the risk over the potential gain IMHO.

Regards,
Volker
--nextPartQfeYe_4WRgCMkavsQJuD8A
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part.
Content-Transfer-Encoding: 7Bit

-----BEGIN PGP SIGNATURE-----

iHkEABECADkWIQQAnu3FVHA48KjZ07R/lszWTRLSRwUCamzEPRsUgAAAAAAEAA5t
YW51MiwyLjUrMS4xMSwyLDIACgkQf5bM1k0S0kdjBgCgi5MTvUlyqrUf/arrihpC
FtlQPUMAoJc8nKzj+XIQAr7+wb9zzm021A9S
=812E
-----END PGP SIGNATURE-----

--nextPartQfeYe_4WRgCMkavsQJuD8A--