std.path review: update

[Jonathan M Davis]

On 2011-07-18 10:51, torhu wrote:
> On 18.07.2011 16:18, Lars T. Kyllingstad wrote:
> > On Mon, 18 Jul 2011 14:23:18 +0200, torhu wrote:
> >> 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
> > "".
> 
> I meant to imply that null and empty should not be used to mean two
> different things, sorry if I didn't make myself clear. AFAIK, none of
> the Phobos functions that take string arguments care about the
> difference. If the length is zero, the pointer value is ignored. In
> light of this, I don't know what different meanings null and empty would
> or should have.

There are definitely situations where it is valuable to differentiate between 
null and empty, but in the case of D arrays, they really aren't designed for 
it, because nearly everything in the language treats them as being the same 
thing. There may be some value in differentiating them in spite of that, but 
it doesn't generally work very well. One of the few places would be the return 
value of a function. So, if there could reasonably be a difference between "" 
and null for the return value of a function, then it could be reasonable to 
null mean something different than "". But the truth is that that's going to 
be error prone, because people are likely to use == null instead of is null, 
not realizing that == null doesn't do what they want (in fact, arguably, == 
null merits a warning). So, if there's no clear gain in returning null, the 
documentation should just say that it returns empty, and then it doesn't 
matter whether it returns "" or null. It _is_ a bit of a conundrum though. I'm 
not sure that making null and "" virtually identical was ultimately a good 
idea, but we're stuck with it at this point.

- Jonathan M Davis