On Mon, 18 Jul 2011 08:23:18 -0400, torhu <no@spam.invalid> 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.
The one that's kind of nice is the if(path.extension), which reads not
only much better than if(path.extension == null), but it's a very common
idiom in many languages (using if to test a string's emptiness). People
are likely to get this wrong (in fact, it may make sense for *all* empty
arrays to evaluate as false for an if condition).
I personally think if there's no real difference, returning null is the
better option based on these points.
However, if there is some performance/maintenance advantage to not
returning null, then just return an empty non-null array and specify in
the API docs that the function returns an empty string.
-Steve
