Is alias equality inconsistent?

[Timon Gehr]

Jonathan M Davis wrote:
> > 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.

I understand that. But that does not mean they should be treated differently where
they can be treated uniformly.
What I am claiming is that 'is' is a feature on the same level as the primitives
listed above.

>
> > 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

As its in TDPL and DMD I think that is pretty much what Walter intended.
'is' is only there because there is no other (safe/convenient) means of testing
for shallow equality in D.
Fixed-size arrays are somewhat special, there 'is' actually compares ptr and
length. I think that is very practical and makes sense because it allows
meaningful 'is' between fixed- and dynamic-size arrays. I guess for value types it
is there for completeness and maybe to enable easier generic programming. We do
not lose anything by having it.


Timon