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
