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'.
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.
Andrei
