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.
By the way, did you read my post in the other thread?
