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

["Miguel V. S. Frasson" <mvsfrasson@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1384 bytes --]

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 <contovob@tcd.ie>
escreveu:

> Michael Heerdegen <michael_heerdegen@web.de> writes:
>
> > "Miguel V. S. Frasson" <mvsfrasson@gmail.com> 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
>

[-- Attachment #2: Type: text/html, Size: 2329 bytes --]