Is alias equality inconsistent?

[Jonathan M Davis]

> Jonathan M Davis wrote:
> > On 2011-05-13 12:30, Timon Gehr wrote:
> > > > Hi,
> > > > 
> > > > I find that comparing for alias equality is a bit odd. Maybe somebody
> > > > can shed some light into it.
> > > > 
> > > > int a = 1;
> > > > int b = 1;
> > > > assert(a is b);
> > > > 
> > > > but
> > > > 
> > > > int[1] aFixedArray = [1];
> > > > int[1] bFixedArray = [1];
> > > > assert(aFixedArray !is bFixedArray);
> > > > 
> > > > It behaves as specified in TDPL p. 57:
> > > > "If a and b are arrays or class references, the result is true if and
> > > > only if a and b are two names for the same actual object;
> > > > Otherwise, a is b is the same as a == b."
> > > > 
> > > > But fixed-size arrays have value semantics as int, float etc. So why
> > > > is alias equality not consistent with value vs. reference semantics?
> > > > Why this exception for fixed-size arrays?
> > > > 
> > > > Jens
> > > 
> > > Hi,
> > > 
> > > I think it is more consistent this way, because static arrays are
> > > closer to dynamic arrays than to int, float etc.
> > > If you write generic code, it is more likely that the template will be
> > > instantiated with for example both of int[6] and int[] than int[6] and
> > > float for the same parameter.
> > > You really want the semantics of 'is' to be consistent between
> > > different array types.
> > 
> > Except that static arrays and dynamic arrays are different beasts and
> > should _not_ be treated the same. A dynamic array which references a
> > static array should be treated the same as another dynamic array, but
> > static arrays and dynamic arrays should _not_ be treated the same.
> > They're very different.
> > 
> > - Jonathan M Davis
> 
> If that is true to the extent implied by you, then D is doing it all wrong
> anyway:
> 
> declaration: int[] arr; vs int[N] arr;
> extract value: arr[x] vs arr[x]
> store value: arr[x] = v; vs arr[x] = v;
> slice: arr[a..b] vs arr[a..b]
> get pointer: arr.ptr vs arr.ptr
> get length: arr.length vs arr.length
> ... (you see where this is going)

They are different because dynamic arrays are reference types and static 
arrays are value types. That has a definite impact when copying and assigning 
them. It has an impact on anything which differs depending on value and 
reference semantics. That can have far-reaching impacts.

> Jonathan M Davis wrote:
> > I'm surprised that is works with value semantics at all. I would have
> > expected that to be a compiler error. Barring that, I would have
> > expected it to be false for value types unless a variable was compared
> > with itself with is. This definitely seems off.
> 
> Not at all. What you suggest is that 'is' should compare the addresses of
> its arguments. It is not at all like that. For classes 'is' compares its
> actual arguments while == has an additional indirection.
> You can think of value types as references to unique immutable data. They
> behave just the same, except that they are more efficient. I think 'is'
> works just as it is supposed to.

It was my understanding that is was specifically intended for comparing 
reference equality. As such, it has no business being used to compare value 
types. If, on the other hand, it is merely doing a comparison with no 
indirections, then is and == would be the same for value types and would make 
sense. I'm not sure what was actually intended by Walter. I am, however, very 
surprised to see is work with value types.

- Jonathan M Davis