The Nullity Of strings and Its Meaning

[ag0aep6g via Digitalmars-d-learn]

On 07/09/2017 03:51 PM, kdevel wrote:
> On Sunday, 9 July 2017 at 10:32:23 UTC, ag0aep6g wrote:
[...]
> 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

Nullity of D strings is quite different from nullity of C strings. A 
null D string is a valid string with length 0. A null char* is not a 
proper C string. It doesn't have length 0. It has no length.

A C function can't return a null char* when it's supposed to return an 
empty string. But a D function can return a null char[] in that case.

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

Just like other pointers are not preserved. In the .ptr field of a D 
array, a null pointer isn't special. Null arrays aren't special beyond 
having a unique name.

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

string is a type that involves a pointer. The type is not opaque. The 
user can access the pointer.

A null array is not some magic (invalid) value. It's just just the one 
that has a null .ptr and a zero .length.

I think that's widely known, but it might not actually be in the spec. 
At least, I can't find it. The page on arrays [1] just says that 
"`.init` returns `null`" and that "pointers are initialized to `null`, 
without saying what null means for arrays. On the `null` expression [2], 
the spec mentions a "null value" of arrays, but again doesn't say what 
that means.

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

As far as I see, you had no reason to assume that. If the spec or some 
other document mislead you, it needs fixing.

[...]
> 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. ;-)

Or the spec's just poorly written there, and wasn't meant the way you've 
interpreted it.


[1] https://dlang.org/spec/arrays.html
[2] https://dlang.org/spec/expression.html#null