bug#34852: 26.1; seq-intersection ignores nil as element

[Basil L. Contovounesios]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

> Yet another approach might be to make an exception in seq-contains if
> the returned element is nil (and return something else in that case).
> E.g.
>
>     diff --git a/lisp/emacs-lisp/seq.el b/lisp/emacs-lisp/seq.el
>     index 4a811d7895..d2398eb588 100644
>     --- a/lisp/emacs-lisp/seq.el
>     +++ b/lisp/emacs-lisp/seq.el
>     @@ -360,7 +360,7 @@ seq-sort-by
>      Equality is defined by TESTFN if non-nil or by `equal' if nil."
>        (seq-some (lambda (e)
>                    (when (funcall (or testfn #'equal) elt e)
>     -                e))
>     +                (or e t)))
>                  sequence))
>      
>      (cl-defgeneric seq-set-equal-p (sequence1 sequence2 &optional testfn)

This is both backward-incompatible and inconsistent.  If we agree to
make a backward-incompatible change, I would rather turn seq-contains
into a proper predicate, as per my second patch.  Besides, returning the
element found isn't particularly useful to begin with, as the caller
already has access to that value.

Either way, we can install the backward-compatible first patch (which
uses seq-position in place of seq-contains) to fix this bug, and later
discuss any backward-incompatible changes to seq-contains.

Thanks,

-- 
Basil