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

From: "Miguel V. S. Frasson" <[email-masked]>
Date: Fri, 15 Mar 2019 13:08:50 -0300

Hi

I was convinced by the discussions here that changing seq-contains is a bad
idea.

I had the false premise that ELT=nil makes seq-contains return nil.

If I could make a suggestion, it would be include an &optional NOT-FOUND to
be the value returned in case of not finding any element matching TESTFN.

Cheers

Miguel

Em sex, 15 de mar de 2019 12:56, Basil L. Contovounesios <[email-masked]>
escreveu:

> Michael Heerdegen <[email-masked]> writes:
>
> > "Miguel V. S. Frasson" <[email-masked]> writes:
> >
> >> In any case, of another implementation for seq-intersection or not, I
> >> think that the solution from Stefan should be implemented anyway
> >> because
> >>
> >> * it makes seq-contains provide a useful return value when ELT=nil, so
> >> it is a good exception; If ELT=nil, seq-contains currently returns nil
> >> anyway;
> >>
> >> * it makes seq-contains become a real predicate function, making it
> >> more useful;
> >>
> >> * since seq-contains has been used as predicate before, it is
> >> unpredictable which code uses it out of official repositories, so this
> >> fix potentially fixes other code.
> >
> > BTW, another (alternative) alternative would be to make it return
> > (list ELT).  That would be a bit less backward-compatible, but a
> > bit more consistent.
>
> +1, either this or returning a boolean is fine with me.
>
> --
> Basil
>