Is alias equality inconsistent?

[Timon Gehr]

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)

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.

Timon