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


View this message in rfc822 format

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: Michael Heerdegen <michael_heerdegen <at> web.de>
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: bug#34852: 26.1; seq-intersection ignores nil as element
Date: Thu, 14 Mar 2019 22:40:27 -0400
>> > (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;"

Duh, sorry, I lost sight of the goal along the way.

A short real counter example is

    (seq-contains '(1) nil #'list)

but it's admittedly contrived.  A more real counter example is the one
alluded to by Nicolas earlier:

    (seq-contains '((t 1) (nil 2)) nil (lambda (x y) (equal x (car y))))

> 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.

The test doesn't need to be an equality test.
IOW seq-contains is very close to seq-find.


        Stefan




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.