Re: Re: [[nodiscard]] and KDE coding policy

On Friday, July 31st, 2026 at 3:26 PM, David Redondo <[email protected]>=
 wrote:

> Am Freitag, 31. Juli 2026, 13:47 schrieb Harald Sitter:
> > On Fri, Jul 31, 2026 at 11:58=E2=80=AFAM Tobias Fella <[email protected]>=
 wrote:
> > >
> > > Hello everyone,
> > >
> > >
> > > On 7/31/26 2:53 AM, Jin Liu wrote:
> > > > Vlad Zahorodnii <[email protected]> =E4=BA=8E2026=E5=B9=B47=
=E6=9C=8831=E6=97=A5=E5=91=A8=E4=BA=94 04:22=E5=86=99=E9=81=93=EF=BC=9A
> > > >> That being said, I still don't think that adding [[nodiscard]] to
> > > >> functions such as getters is a good idea. It makes code more verbo=
se,
> > > >> with more boilerplate, with little (imho) benefit. Stray getter ca=
lls
> > > >> are odd but the effort to avoid them is hard to justify.
> > > > Yeah, I don't think getters need `[[nodiscard]]`, for the same reas=
on that
> > > > `std::min` and `std::move` don't have it:
> > > > 1. It's very unlikely that one would ignore the return value.
> > > > 2. Even when mistakenly ignored, there's no effect.
> > >
> > > 1. We're writing lots of code for things that aren't likely, it's a h=
uge
> > > part of why we have compiler warnings, certain CI jobs, etc. at all.
> > > Yes, it's not likely that you're forgetting to actually do something
> > > with the getter call, but it does happen
> > >
> > > 2. Well, no: There is not going to be an evil side-effect from the
> > > invocation of the getter call, but you're also not doing the thing yo=
u
> > > wanted to do, which could lead to all sorts of problems. This is also
> > > not a theoretical problem, we have recently shipped a (small) bug
> > > because of such a mistake[1]. This is what led me to suggest adding
> > > [[nodiscard]] pretty much anywhere as long as the returned value isn'=
t
> > > really just an optional thing.
> > >
> > >
> > > So yes, I do think we should add it to getters as well, it's a useful
> > > sanity check. That doesn't mean we have to immediately add it to all
> > > existing code or worry too much about forgetting it somewhere. But it=
's
> > > a good thing to aim for.
> >
> > +1
> >
> +1
>=20
> David
>=20
>=20

+1

We can explicitly say that no one should go hunting through old code making=
 noise because it's not there. We can even advise (note advise) against pat=
ches that just add it to old code to avoid the churn and just expect that i=
t gets added the next time that code is touched

James