std.path review: update

[Lars T. Kyllingstad]

On Mon, 18 Jul 2011 09:38:08 -0500, Andrei Alexandrescu wrote:

> On 7/18/11 7:23 AM, torhu 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.
> 
> Note that there are two aspects: generating 'nothing here' values, and
> testing for 'nothing here'.

Some have argued that there is an extra dimension to this, namely the 
distinction between "nothing here" and "something here, but that 
something is an empty string".  I am not convinced we should make that 
distinction.


> In keeping with the "be generous with what you receive and conservative
> with what you send" mantra, good functions should test string inputs
> with str.empty and return null strings.

The specific example which spurred the debate was the following:

While there is no doubt that extension("foo") should return null, 
Vladimir Panteleev argued that extension("foo.") should be *specified* to 
return "" (specifically, an empty slice from the end of the input string) 
to indicate that there is an "empty extension".

I disagree, I don't think null and "" should have different semantics.  
The fact that extension() currently *does* behave as Vladimir wants is, 
in my opinion, an implementation detail.

Note that extension() seems to be the only function for which the 
controversy has arisen so far, so it may not be worth taking this 
discussion too far.

-Lars