input validation

[Andrei Alexandrescu]

Sean Kelly wrote:
> I'm not terribly fond of the added verbosity however, or that this seems 
> like I couldn't use the property form:
> 
>     assumeSorted("abcd").find('c')
> 
> Truth be told, my initial inclination would be to repackage the binary 
> search as a one-liner with a different name, which kind of sabotages the 
> whole idea.  But I'll try to resist this urge.

I understand. This is rather new, but I found it irresistibly cool to 
unify find() routines under one name and specify structure in the 
arguments' types. Usage is very easy, there's little to remember, and 
every piece of structure is where it should be. Consider:

int[] a = [ 1, 2, 3, 4 ];
int[] b = [ 2. 3 ];

These algorithms each performs search a different way because each is 
informed in different ways about the structure of their arguments:

find(a, b);
find(assumeSorted(a), b);
find(a, assumeSorted(b));
find(assumeSorted(a), assumeSorted(b));
find(a, boyerMooreFinder(b));

There's three names to remember that compose modularly. The 
run-of-the-mill approach is:

find(a, b);
binaryFind(a, b);
findRhsSorted(a, b);
binaryFindRhsSorted(a, b);
boyerMooreFind(a, b);

To add insult to injury, boyerMooreFind is not enough because it hides 
the structure created around b. So there's also need for one extra type 
e.g. BoyerMooreFinder!(int[]) for cases when there are multiple searches 
of the same thing. It's just onerous.


Andrei

P.S. By the way, this is the running example used in Chapter 4 of TDPL.