std.string and std.algorithm: what to do?

[Steven Schveighoffer]

On Thu, 14 May 2009 17:21:02 -0400, Derek Parnell <derek at psych.ward> wrote:

> On Thu, 14 May 2009 16:59:32 -0400, Steven Schveighoffer wrote:
>
>> I guess I understand the mentality of picking -1 or uint.max as a
>> reasonable "failure" return, but what I don't understand is why you  
>> would
>> do so when you could use the length of the string, which is useful for
>> many other purposes.  -1 or uint.max just is a failure, and needs to be
>> checked, it can't be used to do any slicing operations.
>
> A problem with .length is that it requires the knowledge of the string  
> for
> it to be meaningful. If find() can return any integer, we can only know  
> if
> that integer represents WasFound or WasNotFound if we have the string in
> context.
>
> Currently we can do this ...
>
>     funcA( find(needle, haystack), xyzzy);
>
> and 'funcA' doesn't need to know anything more about the 'haystack' to
> work. If find/indexOf() can return any integer we would have to code ...
>
>     funcA( indexOf(needle, haystack) != haystack.length ? uint.max : 0,
> xyzzy);
>
> (assuming that funcA is expecting uint.max to mean WasNotFound).
>
> So there are really arguments for employing both methods. It just depends
> on why you are trying to 'find' stuff.

Not really.  What could funcA possibly do with the index without the  
string itself?  If it's just a flag (uint.max or not), then funcA should  
be:

funcA(bool found, ...)

and you call it with

funcA(find(needle, haystack) < haystack.length, xyzzy)

This doesn't cause any problems with people who use Tango, which returns  
the length if not found.  In other words, if you find yourself writing  
code to "morph" the length into uint.max or -1, you are thinking about the  
problem incorrectly.

-Steve