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
