std.path review: update

[Lars T. Kyllingstad]

On Mon, 18 Jul 2011 14:23:18 +0200, 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.
> 
> As far as I can tell by the testing I've done, you can use a null string
> in every way that you can use an empty string, even append to it with
> ~=.   The distinction between null and empty strings is significant in C
> and Java, but in D it's not, and the tiny difference that actually
> exists mainly serves to confuse people.  It doesn't help that the actual
> differences are largely undocumented either.
> 
> One difference is that a statically allocated empty string is null
> terminated, but I think that can be safely ignored in the case of return
> values.

True, but the question was not whether one should use null or "" for the 
"nothing here" return value of a function.  The question was whether the 
function returning null should mean something different than it returning 
"".


> By the way, did you read my post in the other thread?

Yes, I read it, but I forgot to answer.  Sorry about that.  I've answered 
now.

-Lars