On Friday, 1 August 2014 at 21:36:14 UTC, Chris Cain wrote:
On Friday, 1 August 2014 at 07:51:32 UTC, Andrew Godfrey wrote:
Going through other .dd files, I found an error in
expression.dd.
It says "For static or dynamic arrays, identity is defined as
referring
to the same array elements and the same number of elements."
Well, in fact:
unittest {
// expression.dd says that equality AND IDENTITY compare
elements and sizes, for both "static and dynamic arrays". Gaah!
int[] a = new int[3];
int[] b = new int[3];
assert(a == b);
assert(a !is b); // Nope! The doc is wrong!
// So then:
b = a;
assert(b is a); // Now b points to a, and 'is' does what
I'd expect.
// But evidently it's because it compared the array
references - not
// the elements and sizes!
}
I would NOT recommend updating the compiler to match what the
doc says.
The current behavior is consistent with how assignment to an
array reference behaves.
I think the docs might can be cleared up in this regard, but
from my reading, the docs are correct on this.
int[] a = new int[3];
and
int[] b = new int[3];
Do not refer to the same elements. They are two different
allocations that happen to look alike and compare equal, but
they aren't referring to the same point in memory.
To prove this, you can simply do `a[0] = 1;` ... did `b[0]`
"change" as well? (No). Then they couldn't possibly have been
referring to the same thing.
What the docs are saying by "referring to the same array
elements and the same number of elements": basically, an array
in D is simply a pointer + length struct. The `is` operator
essentially does a bitwise compare, so naturally `a is b` only
returns true when they are bitwise identical structs, which
must mean they are the same in both pointer and in length,
which naturally means that `a == b` as well. There's no need to
compare elements since there's no way something doesn't equal
itself unless some weird trickery is going on (concurrent
modification?).
You can imagine `is` to mean `a.ptr == b.ptr && a.length ==
b.length` (or that they refer to the same array and they have
the same number of elements), but implemented in what is
probably a more efficient manner.
Yes, I was a bit terse in my previous retraction (was low on
time). I realized this is what the doc was actually saying. The
edit in the PR stands, but my description of it as fixing an
"error" is incorrect.
The language was just a bit confusing, perhaps.
I am unable to fix the PR description at the moment but that
shouldn't prevent review of the PR itself.
