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.
