GNU bug report logs - #34852
26.1; seq-intersection ignores nil as element

Previous Next

Package: emacs;

Reported by: "Miguel V. S. Frasson" <mvsfrasson <at> gmail.com>

Date: Thu, 14 Mar 2019 02:24:01 UTC

Severity: normal

Tags: fixed

Found in version 26.1

Fixed in version 27.1

Done: Nicolas Petton <nicolas <at> petton.fr>

Bug is archived. No further changes may be made.

Full log


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

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
Cc: "Basil L. Contovounesios" <contovob <at> tcd.ie>,
 Nicolas Petton <nicolas <at> petton.fr>, 34852 <at> debbugs.gnu.org,
 "Miguel V. S. Frasson" <mvsfrasson <at> gmail.com>
Subject: Re: bug#34852: 26.1; seq-intersection ignores nil as element
Date: Fri, 15 Mar 2019 00:42:39 +0100
Stefan Monnier <monnier <at> IRO.UMontreal.CA> writes:

> > (seq-contains nil '(nil t foo) (lambda (x) t))  ->  nil
> > It returns *nil* if testfn fails, or *nil* (ELT) if it succeds.
>
> Just because it sometimes does doesn't mean it always does:
>
>     (seq-contains '(0 3 4) 1 #'<)
>
> returns 3

Maybe it's too late here, but why is that a counterexample for

> If ELT=nil, seq-contains currently returns nil anyway;"

The first element is returned for that the test succeeds, what's special
about it?  < is not symmetrical, though, so it's a weird kind of
equality test.


Michael.




This bug report was last modified 6 years and 64 days ago.

Previous Next


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