RE: [sv-ec] mantis item 3279

Jonathan,

Regarding your proposal to redefine "assignment compatible" as unidirectional:

Note that 6.22.3 already says, "Compatibility can be in one direction only. For example, an enum can be converted to an integral type without
a cast, but not the other way around. Implicit casting rules are defined in 6.24." I agree that this statement is not sufficient, as it does not say when it is unidirectional and when it is bidirectional, but it already expresses the possibility that this can occur.

More importantly, if you redefine 'assignment compatible', then it is also necessary to examine all 30 uses of the term in the LRM to clarify in each whether the compatibility is unidirectional or bidirectional.

Editorial note: "assignment compatible" is written sometimes with a hyphen between the words and sometimes without. The use should be consistent.

Regards,
Shalom

From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of Jonathan Bromley
Sent: Monday, February 21, 2011 10:19 PM
To: Francoise Martinolle
Cc: sv-ec@server.eda.org
Subject: 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<http://www.mailscanner.info/>, and is
believed to be clean.
---------------------------------------------------------------------
Intel Israel (74) Limited
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.