The Nullity Of strings and Its Meaning

[ag0aep6g via Digitalmars-d-learn]

On 07/09/2017 01:12 AM, kdevel wrote:
> On Saturday, 8 July 2017 at 18:39:47 UTC, ag0aep6g wrote:
>> On 07/08/2017 07:16 PM, kdevel wrote:
> 
>> null is one specific array. It happens to be empty, but that doesn't 
>> really matter. `foo is null` compares with the null array. It doesn't 
>> check for emptiness. Conversion to bool also compares with null. The 
>> concept of emptiness is unrelated.
> 
> But why? What is the intended use of converting a string (or any other 
> dynamic array) to bool?

As I said: I wouldn't mind if it went away. I don't see a strong use 
case that justifies the non-obvious behavior of `if (arr)`. But 
apparently it is being used, and breaking code is a no-no.

As for how it's used, I'd start digging at the link Timon has posted.

> In Issue 17623 Vladimir pointed out, that in the case of strings there 
> may be a need to store an empty D-string which also is a NUL-terminated 
> C-String. It would be sufficient if the ptr-Value would convert for 
> checking if there is a valid part of memory containing the NUL byte.

But just looking at .ptr doesn't tell if there's a '\0'. You'd have to 
dereference the pointer too.

And that's not what Vladimir is getting at. Issue 17623 is about `arr1 
is arr2`, not about conversions to bool like `if (arr)`. It makes sense 
that `null !is ""`. They're not "the same". One place where the 
difference matters is when working with C strings.

Issue 17623 is absolutely valid. But it's much more likely that the spec 
will be changed rather than the implementation.

> Moreover everything I've written about strings is also valid for e.g. 
> dynamic arrays of doubles. Here there are also two different kinds of 
> empty arrays which compare equal but are not identical. I see no purpose 
> for that.

So you'd make `arr1 is arr2` true when they're empty, ignoring a 
difference in pointers. Otherwise, it would still compare pointers. Right?

I don't think that's a good idea, simply because it's a special case.

I noticed that you haven't mentioned `==`. You're probably aware of it, 
but if not we might be talking past each other. So, just to be clear: 
You can also compare arrays with `==` which compares elements. `null == 
""` is true.

>> You only get surprised if you expect that to check for emptiness (or 
>> something else entirely).
> 
> As mentioned I was surprised, that the non-nullity did not pass thru 
> decodeComponent.

decodeComponent doesn't seem to return the same (identical) string you 
pass it, most of the time. Try "foo":

----
void main()
{
     import std.uri;
     string a = "foo";
     auto s = a.decodeComponent;
     assert(s == a); /* passes */
     assert(s is a); /* fails */
}
----

decodeComponent simply gives no promise of preserving pointers. You also 
shouldn't rely on it returning null for a null input, even when it 
currently does that.

>> The spec isn't very clear there. What does "the same array elements" 
>> mean for empty arrays?
> 
> Mathematically that's easily answered: 
> https://en.wikipedia.org/wiki/Universal_quantification#The_empty_set

So "two empty arrays refer to the same elements" is true because 
everything said about the elements of empty arrays is true? Is "two 
empty arrays do *not* refer to the same elements" also true?