The Nullity Of strings and Its Meaning

[kdevel via Digitalmars-d-learn]

On Sunday, 9 July 2017 at 10:32:23 UTC, ag0aep6g wrote:
> 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:

[...]

>> 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?

As a D novice am not in the position to suggest changes in the 
language (yet).
I would appreciate a documentation that accurately represents 
what is implemented.

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

As mentioned in the subject my posting is about the state of 
affairs wrt. the (non-)nullity of strings. In C/C++ once a char * 
variable became non-NULL 'it' never loses this property. In D 
this is not the case: The non-null value ""
'becomes' null in

    "".decodeComponent

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

Sure. But I am writing about the string value which comprises the 
(non-)nullity of the string. This is not preserved.

[...]

> decodeComponent simply gives no promise of preserving pointers.

string is not a pointer but a type. To the user of string it is 
completely irrelevant, if the nullity of the string is 
implemented by referring to a pointer inside the implementation 
of string.

> You also shouldn't rely on it returning null for a null input, 
> even when it currently does that.

I assumed that a non-null string is returned for a non-null input.

>>> 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?

Yes. But that second proposition what not the one chosen in the 
documentation. It was not chosen because it does not extend to 
the nontrivial case where one has more than zero elements. ;-)

Stefan