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

[Miguel V. S. Frasson]

Hi

Maybe this is the same bug, now with seq-difference

(seq-difference '(nil) '(1 nil) #'eq)
-> (nil)

(In my applications, nil is a frequent element of my lists)

Is this fixed by the proposed patches?


Cheers.

Miguel

Em sex, 15 de mar de 2019 às 13:08, Miguel V. S. Frasson
<mvsfrasson@gmail.com> escreveu:
>
> 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



-- 
Miguel Vinicius Santini Frasson
mvsfrasson@gmail.com