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?
