equivariant functions

[Andrei Alexandrescu]

Steven Schveighoffer wrote:
> "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).

Well I agree. I was just pointing out a minute fact.

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

Yah, that's where the PassQual template is needed. I'd agree without joy 
that, if handling true equivariance is too unwieldy, we can resign to 
solving only equivariance in qualifier.


Andrei