Re: master 2bb0703 1/2: lisp/*.el: Force non-nil result to t, to match docstring

[Stefan Monnier <monnier@iro.umontreal.ca>]

Just to be clear: this is a typical bikeshed subject.

Some people think functions that return booleans should return nil/t and
other think they should return nil/non-nil.  It's a question
of opinion.  There are advantages on both sides.

So far, AFAIK most of the code and docstrings use nil/non-nil, AFAICT
(which is why we're all familiar with the notion of "non-nil" as
a matter of fact) and as a maintainer I've made an effort to try and
standardize on this, e.g. by fixing docstrings which overspecified the
return value to `t`.

This is similar to the issue of documenting side-effecting function's
return value versus discouraging the use of their return value.

The most important thing is to try and choose one and stick to it, both
for the benefit of consistency and to avoid back-and-forth
cosmetic changes.


        Stefan


Juanma Barranquero <lekktu@gmail.com> writes:

> The issue here is not transforming every "predicate" -p function into one
> returning t/nil. That's not what my patches did. And in my original answer
> I already said that most predicates return t/nil, but not *all*. I would
> contend that "predicates" not returning t/nil aren't really predicates, but
> that's a discussion for another day.
>
> Most of my latest patches make the function follow its documented interface
> (the docstring), which shouldn't be so controversial. In fact, if some
> function relied on the documented t result, if was risking getting
> something different, often in obscure cases. So I'd say this patch will
> help uncover bugs. (I'd be surprised that a function, for example,
> documented as "return t", returning a marker in *some* cases, is being used
> purposely so by the client code.)
>
> In other cases, they fix problems; either because the docstring says that
> it returns t, but in fact they return a useful non-nil value, or because
> the functions say non-nil/nil, but are in fact functions that, but it's
> very nature, will always return only t/nil. That shouldn't be
> controversial, either.
>
> I mean, if some specific change in my patches is a mistake, let's discuss
> it or fix it. But mostly, what I've done is fixing latent bugs, either in
> the documentation or the code.