The way I understand this, is any new sequence type has to implement
seq-do. As soon as that happens, a lot of (probably all) sequence
functions in seq.el start working on that type.
Right. But seq-difference-3 doesn't call into seq-do anymore,
at least not always and not in the same way. So today,_before_
your seq-difference "skips-the-seq-do" optimization, a given person's
set difference operations would work just fine for their custom
data type. The person is happy and doesn't care about seq.el's
performance.
One day they upgrade seq.el which comes with your optimization to
seq-difference, and that code is mysteriously broken. Worse for some
equality predicates it is broken in a given way, for other equality
predicates it's a different error.
Can't you see the fundamental problem?
Right, but then if they fail the customization of the entry point
generic like not calling the right generics at the right time, then
_other_ customizations of_other_ generics won't be called, or will
be called too much. Just like in your seq-difference-3 optimization
the user code breaks.
cl-{n}set-difference are standard stuff in the CL world. There are even
reference LOOP implementations (likely much more performant than ours,
though possibly not compatible with some non-standard edge cases our
cl-loop has of which I know a couple).
I do believe it's helpful to have it around.
What is?