GNU bug report logs - #42871
28.0.50; Documentation for `seq-contains-p` is outdated

Previous Next

Full log

Message #16 received at 42871 <at> debbugs.gnu.org (full text, mbox):

From: "Basil L. Contovounesios" <contovob <at> tcd.ie>
To: Iwan in 't Groen <iwanintgroen <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 42871 <at> debbugs.gnu.org
Subject: Re: bug#42871: 28.0.50; Documentation for `seq-contains-p` is outdated
Date: Wed, 19 Aug 2020 11:56:45 +0100

Iwan in 't Groen <iwanintgroen <at> gmail.com> writes:

> The return value in the description of this function (now a predicate) should also be changed.
>
> Currently is says:
> This function returns non-‘nil’ if at least one element in SEQUENCE is equal to ELT.
>
> It should be:
> This function returns ’t’ if at least one element in SEQUENCE is equal to ELT.
>
> diff --git a/doc/lispref/sequences.texi b/doc/lispref/sequences.texi
> index ca52369bd0..bb80307c8c 100644
> --- a/doc/lispref/sequences.texi
> +++ b/doc/lispref/sequences.texi
> @@ -784,7 +784,7 @@ Sequence Functions
>  
>  
>  @defun seq-contains-p sequence elt &optional function
> -  This function returns non-@code{nil} if at least one element in
> +  This function returns @code{t} if at least one element in
>  @var{sequence} is equal to @var{elt}.  If the optional argument
>  @var{function} is non-@code{nil}, it is a function of two arguments to
>  use instead of the default @code{equal}.

I don't feel strongly about this, but note that in general it's common
and fine to say non-nil in place of t, even when the value is t.
Predicates are allowed to return other non-nil values too, see
e.g. proper-list-p.  The only time the distinction matters enough to
document it is when different non-nil values have different meanings,
e.g. with while-no-input or with certain user options.

HTH,

-- 
Basil

Previous Next

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