A case for opImplicitCast: making string search work better

[grauzone]

> to return a pair struct, but still, what could be simpler than returning 
> an index?  It's easy to construct the value you want (before or after), 
> and if you both multiple values, that is also possible (and probably 
> results in simpler code).

All what you can do with the index is
1. compare it against the length of the searched string to test if the 
search was successful
2. slice the searched string
3. do something rather special

What else would you do? You'd just have to store the searched string as 
a temporary, and then you'd slice the searched string (for 2.), or 
compare it against the length of the searched string. You always have to 
keep the searched string in a temporary. That's rather unpractical. Oh 
sure, if you _really_ need the index (for 3.), then directly returning 
an index is of course the best way.

With my approach, you don't need to grab the passed searched string 
again. All of these can be done in a single, trivial expression (for 3. 
getting the index only). Actually, compared to your approach, this would 
just eliminate the trivial but annoying slicing code after the search 
call, that'd you'd type in... what, 90% of all cases?

The thing about multiple return values is true (sadly), but in this 
case, you could simply return a static array (char[][2]). At least that 
should be possible in D2 at some point.

Maybe a struct would work fine too. But I don't like it, because the 
programmer had to look up the struct members first. He had to memorize 
the struct members, and couldn't tell what the function returns just by 
looking at the function signature.

(Yay bikeshed issues.)