input validation

[bearophile]

Andrei Alexandrescu:
> Of five, three are frequent (linear, binary, Boyer-Moore), one is a form
> of set intersection (find sorted in sorted),

Yeah. Sorted-array-based sets are probably common enough in C++ code (but I generally use something equivalent to hash-sets for this purpose, I have even mostly implemented such class for D1 in the dlibs, with a nice API).
(I see sorted-array-based sets as an optimization to use in special cases, while hash-sets are for the general case when you want to manage sets (in D hashing needs a comparison too because of the chains are external and tree-based, but some other languages for hash-sets you need just hashability and not sortability of items)).


> and the odd one is:
> find(a, assumeSorted(b));
> This is rare but has excellent best-case complexity (is it O(a.length /
> b.length)?) and is easy to add for completeness.

I suggest you to not add this uncommon case, and add it only if later there are enough people asking for it. Less code to write and maintain.
Creating functions and algorithms is a matter of balance between over-generalization (that often leads to useless complexity and longer syntax) and too much "special casing" that has other problems. Both extrema aren't good.
Life isn't easy, I guess we are asking you to be a cross between Alexander Stepanov and Guido van Rossum :o)


> Returning int from find is an insult. To add injury to it, have find 
> also return an int for a list.

So you return an iterator, and no exception is raised, I see. I like this enough.

Bye,
bearophile