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
