equivariant functions

[Steven Schveighoffer]

"Andrei Alexandrescu" wrote
> Steven Schveighoffer wrote:
>> These are similar, if you consider that const is a 'base type' of its 
>> mutable or invariant version.  But there is one caveat that is hard to 
>> explain using this terminology.  const is a type modifier, not a type. 
>> So it's not really a base type of a type, and it can be applied to any 
>> type in existance.  Not the same as specifying a base type.
>
> Base type and supertype are not to be confused. By base type I understand 
> you mean you actually type class Super{} and class Sub:Super{}. The 
> subtyping relation is more general and applies to any two types Super and 
> Sub that satisfy a number of constraints.
>
> That const(T) is a supertype of both T and invariant(T) is essential and 
> not happenstance. It enshrines the fact that you can always pass a T or an 
> invariant(T) into a function. The fact that there is no difference in 
> layout and that const is not assignable also means that arrays of const(T) 
> are supertypes of both arrays of T and invariant(T), with important 
> consequences.

But a type invariant(T) is not a subtype of const(U).  How do you solve this 
problem:

class U
{
   private T field
   public T property() { return field;}
   public invariant(T) property() { return field; } invariant;
   public const(T) property() {return field; } const;
}

Because T is completely unrelated to U, so the inout contract only has to do 
with constancy, not the types.

-Steve