GNU bug report logs - #78704
[PATCH] Use `seq-do' instead of `seq-map' for side-effects

Previous Next

Full log

View this message in rfc822 format

From: Zach Shaftel <zach <at> shaf.tel>
To: Pip Cet <pipcet <at> protonmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 78704 <at> debbugs.gnu.org, Nicolas Petton <nicolas <at> petton.fr>, Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: bug#78704: [PATCH] Use `seq-do' instead of `seq-map' for side-effects
Date: Sat, 07 Jun 2025 15:06:15 -0400

Pip Cet <pipcet <at> protonmail.com> writes:

> But I'm not sure adding important-return-value to functions which aren't
> usually side-effect-free is a good idea given the warnings it currently
> produces.

my understanding was that important-return-value is meant to instruct
the compiler to warn about discarded values, without also allowing it to
optimize away those calls the way the side-effect-free property does
(for example, `mapcan' is declared important-return-value). so
side-effect-free implies important-return-value. is that not the
intended meaning?

> The main reason is that it's not a helpful warning unless we tell the
> user which function to use instead: mapc is a special case which is
> handled by an explicit message, but without a "use `seq-do' instead"
> in the message, fixing the warning requires looking up docstrings to
> find the right alternative, which might not exist.

very true. maybe important-return-value could accept a string argument
to specify a helpful message? this could also be useful for functions
like `plist-put', which are side-effect-full but whose return value
should still be captured; we could notify the user that
(plist-put plist :prop val) should be wrapped with `setq'.

> Some other languages have chosen a different approach and provide a way
> for functions to know, at compile time or run time, whether their return
> value is used in a particular call.  

interesting, i wasn't aware of that approach. where could i see some
examples?

> Maybe we should do that instead? As an analogy, the byte compiler
> won't complain about (equal x 3), but will silently replace it by (eq
> x 3), so it's not like we always warn the user about code which can be
> optimized in a similar fashion.

that seems appropriate to me. (equal x 3) is still a valid usage of the
`equal' function, and will do what the user intended. on the other hand,
we do complain about (eq x '(t)) in bytecomp--warn-dodgy-eq-arg, because
that almost certainly will not do what the user intended.

> However, I did notice that we warn about fewer important-return-value
> functions than I thought, and opened bug#78716 to discuss whether we
> should add more warnings.
>
> Pip

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.