A case for opImplicitCast: making string search work better

[grauzone]

> a good point.  The only drawback in this case is you are constructing 
> information you sometimes do not need or care about.  If all you want is 
> whether it succeeded or not, then you don't need two ranges constructed 
> and returned.  But therein lies a fundamental tradeoff that cannot be 
> avoided.  The very basic information you get is the index, and with 
> that, you can construct any larger pieces from the pieces you have, but 
> not always easily, and not without repeating identifiers.

The whole point of the search function is to make programming easier, 
isn't it? Its implementation is rather trivial. You call it because it 
makes your life easier. I don't see why constructing this "additional 
information" is a problem.

Anyway, you always could move this to a second function. I just think 
that returning a tuple of slices is the most useful way.

> I like your approach, but with the single return type, not out 
> parameters.  Having out parameters would be a deal breaker.

I just wanted to show something, that works on D1 without memory 
allocation. And without returning a struct.

> If this were implemented, the return type would be very common.  At some 
> point you have to look up everything (what's a "range"?).

I think multiple return values are simpler, and more versatile, elegant 
and intuitive. I contrast, having to define structs for return values of 
(almost) trivial functions is not a good sign. You could as well pass 
all in-parameters of a function as struct, claiming this is more 
practical, because then you can have named arguments and arbitrary 
default arguments. Huh.