std.path review: update

[Steven Schveighoffer]

On Mon, 18 Jul 2011 08:23:18 -0400, torhu <no at spam.invalid> wrote:

> On 18.07.2011 11:42, Lars T. Kyllingstad wrote:
>> On Sun, 17 Jul 2011 22:38:43 -0700, Jonathan M Davis wrote:
>>
>>>  On Sunday 17 July 2011 22:08:27 Brian Schott wrote:
>>>>  The documentation comments for driveName say that the return value  
>>>> will
>>>>  be an empty string in some circumstances, but the code and unit tests
>>>>  both say that the behavior is to return null.
>>>
>>>  The fun part with that is that "" == null and a null string is empty  
>>> per
>>>  std.array.empty, so it _is_ the empty string. The only difference is
>>>  that "" !is null. So, if the function says that it returns null, then  
>>> it
>>>  needs to return null. Since it says that it returns the empty string,  
>>> it
>>>  could return either.
>>>
>>>  Now, in spite of all that, there's still a problem since the tests
>>>  verify that the return value is null, not empty. Either the
>>>  documentation should say that it returns null, or the tests should be
>>>  checking for empty, not null. But still, the documentation isn't
>>>  incorrect. Are the tests are perfectly valid, but they really  
>>> shouldn't
>>>  be testing for is null instead of empty when the function is supposed  
>>> to
>>>  return empty.
>>
>> Pending a decision on the null vs. empty issue, I have now standardised
>> on using empty() for testing whether functions return empty strings.
>
> I'd like to make a case for null as the 'nothing here' value.
>
> The advantage of using null is that all possible ways of testing for  
> 'nothingness' (is, ==, as a boolean condition, empty range) will work.  
> But if you return an empty string, you can't do 'str is null', because  
> that will be false.  With null there's just no doubt, and no way to get  
> the test wrong.

The one that's kind of nice is the if(path.extension), which reads not  
only much better than if(path.extension == null), but it's a very common  
idiom in many languages (using if to test a string's emptiness).  People  
are likely to get this wrong (in fact, it may make sense for *all* empty  
arrays to evaluate as false for an if condition).

I personally think if there's no real difference, returning null is the  
better option based on these points.

However, if there is some performance/maintenance advantage to not  
returning null, then just return an empty non-null array and specify in  
the API docs that the function returns an empty string.

-Steve