Re: [sv-ec] mantis item 3279

On 17/02/2011 23:13, Francoise Martinolle wrote:
> I uploaded a proposal for 3279 (covariant types).
> Please read and send comments.
>
Françoise,

A couple of comments:

- Your definition of covariance (for 6.22.4) seems to me to suffer the
same problem that we already have for the definition of assignment
compatibility. The phrase "A derived class type and its parent class
types are said to be covariant" makes the relationship appear
symmetrical, when in reality of course it's not. Your second phrase of
that sentence really clears up any doubt, but I'd be happier if we could
find a solid definition of the unidirectional covariance relationship.

- Your text for 8.19 describes an important special case: it makes sense
only if the method returns a result of the class's own type, doesn't
it? I suspect the text would be clearer if this requirement were made
explicit.

Here's a tentative shot at a more rigorous definition of the relationship:

- Modify 6.22.3 to define "assignment-compatible with" in a
unidirectional manner as follows:
If type TR is assignment-compatible with type TL then it is legal to
assign an expression of type TR to a target of type TL. The inverse
relationship does not necessarily hold.

- Define covariant return types thus:
Consider a class C having some virtual method F with a return or
output-argument type T1. If C is assignment-compatible with T1 then an
overloaded definition of F, in any class D that is derived from C, may
replace type T1 with a different type T2 provided that D is
assignment-compatible with T2. An argument or return type that has been
replaced in this manner in a derived class is a /covariant/ type.

I believe that this definition allows covariance at any level of the
inheritance hierarchy, but I haven't yet put in the spadework to do a
formal proof and I'd be happy to be proven wrong. I think it also copes
with the possible new wrinkles added by interface classes.

What I do feel rather strongly, though, is that the time has come for us
to embrace rather more rigorous definitions, particularly for things so
fundamental as the type system. Without them we condemn ourselves to
endless wordsmithing that likely opens as many ambiguities as it plugs.

-- 
Jonathan Bromley
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.