Difference between revisions of "Default and explicit variance"

m (Add precision)
(General Refactoring and little change for simplicity)
Line 2: Line 2:
 
[[Category:Catcall]]
 
[[Category:Catcall]]
 
{{Research}}
 
{{Research}}
=== Introduction ===
+
== Introduction ==
This solution enables covariance and contravariance redefinition.
+
In first the limited variant typing is exposed. It checks all catcall checkpoints.
The default behavior is detected automatically. When there is a catcall risk the programmer must explicitly declare the variance.
+
In the second part the mechanism is extended. It is less simple and explicit, but it enables a best transition.
  
== Default variance ==
+
== Limited variant typing ==
=== Feature redefinition ===
+
* Covariant redefinition of request result is allowed
+
* Contravariant redefinition of feature arguments is allowed
+
 
+
The first is a weaker precondition and the second is a stronger postcondition.
+
Only the second rule is a new possibility in Eiffel.
+
 
+
* Contravariant redefinition of request result is allowed for non-conforming inheritance
+
* Covariant redefinition of feature arguments is allowed for non-conforming inheritance
+
 
+
=== Generic conformance ===
+
Generic conformance is close from redefinition.
+
 
+
* Generic used only on feature argument is contravariant.
+
* Generic used only on request result is covariant.
+
* Generic used both on feature argument and request result is novariant.
+
 
+
And then generic not used is covariant and contravariant.
+
 
+
The first checkpoint "Generic lists" is checked.
+
As explained for [[Usage-site variance]] the generic 'OPEN_ARGS' from ROUTINE, PROCEDURE, FUNCTION, PREDICATE must be contravariant.
+
 
+
However 'OPEN_ARGS' is novariant.
+
Indeed the generic is used on request result type and feature arguments.
+
 
+
The class should probably be redesigned. Indeed if contravariant is allowed then there may be a new contravariant catcall on request result.
+
 
+
In these classes there are only two requests using the generic as type:
+
<e>
+
operands: detachable OPEN_ARGS
+
 
+
empty_operands: OPEN_ARGS
+
do create Result ensure ... end
+
</e>
+
 
+
The second request is not used internally and may be problematic for creation: How create a tuple of not self-initialized and attached types?
+
The first is used in these features : 'target', 'is_equal', 'set_operands', 'copy', 'apply'
+
 
+
'is_equal', 'set_operands' and 'copy' rely on data model.
+
'apply' and 'target' are more sensitive. Indeed the problem is when there is an opened target.
+
 
+
'apply' could be restricted for no opened arguments.
+
<e>
+
apply
+
require
+
no_operands: open_count = 0
+
do
+
call (Void)
+
end
+
</e>
+
'target' could be modfied:
+
<e>
+
target: ANY
+
require
+
is_target_closed
+
do
+
-- ...
+
end
+
</e>
+
 
+
Or maybe it is better to separate opened target and closed target in two abstractions.
+
 
+
The redesign of agent classes is an opportunity to solve agent problems (see [[Minor-ECMA-problems]], [[Agents in SCOOP]]).
+
 
+
Another solution will be mentioned later.
+
 
+
Note:
+
The generic 'RESULT_TYPE' of FUNCTION class is used only on request result. Then it is a covariant generic. It is an expected point.
+
 
+
=== Sub-conclusion ===
+
The default semantic use no new keyword.
+
 
+
The lack of expressivity for generic variance can be reduced with a prefixed mark for a formal genric (see [[Default and explicit variance#Ensure the generic variance|below]]).
+
 
+
The addition in TYPE class for reflexivity and dynamic object test is little.
+
Indeed two simple booleans "is_contravariant" and "is_covariant" for each generic is required.
+
<e>
+
generic_parameter_contravariant (i: INTEGER): BOOLEAN
+
-- Is `i'-th generic parameter contravariant?
+
+
generic_parameter_covariant (i: INTEGER): BOOLEAN
+
-- Is `i'-th generic parameter covariant?
+
</e>
+
 
+
== Variant typing ==
+
 
What is the advantages of covariance compared to a novariant typing?
 
What is the advantages of covariance compared to a novariant typing?
 
* explicit and adaptative interface
 
* explicit and adaptative interface
 
* One routine
 
* One routine
  
=== Feature redefinition ===
+
=== Variant typing ===
These rules concern the conforming inheritance.
+
* A variant entity has '''the most restrictive type'''.  
* Covariant redefinition of feature argument requires a 'variant' typing on redefined feature or first feature definition.
+
* A variant antity requires a simple object test to use the entity with the '''expected type'''.
* Contravariant redefinition of request result requires a 'variant' typing on first feature definition.
+
  
The contravariant redefinition has no interests for non-generic and little interests for generics. It can be avoided with a [[Default and explicit variance#Right abstraction|right abstraction]].
+
Examples are available in next sections.
  
Variant typing for Covariant redefinition:
+
=== Feature redefinition ===
* A variant type argument has the most restricted type: The type of the previous definition
+
* Covariant redefinition of request result is allowed (as currently).
* A variant type argument requires a simple object test to use the argument with the expected type.
+
* Covariant redefinition of feature argument requires a variant typing on redefined feature or first feature definition.
* A variant type argument can be assigned to a formal and variant type argument if the most restricted type of the argument is conform to the most restricted type of the formal argument.
+
'''The most restrictive type''' for a variant type argument is the type of the first feature definition.
 +
* Contravariant redefinition of feature arguments is allowed, but the type must be the same than the first feature definition or a subtype.
  
If contravariant redefinition of fetaure argument is allowed then the variant mark must be removed if the type become the most restricted (original) type or a parent of this type.
+
The first rule is a stronger postcondition. The current semantic is not changed.
 +
The last rule is a new possibility in Eiffel, it is a weaker precondition.
  
 
'''example 1:''' covariant redefinition of feature argument with 'variant' typing on redefined feature
 
'''example 1:''' covariant redefinition of feature argument with 'variant' typing on redefined feature
  
Note that the type is not repeated in the object test.
+
Note:
In the interface of the current type the 'variant' is removed. Indeed, it is not possible to call 'eat' on a COW instance with a parameter of type FOOD.
+
* The object test is not needed.
 +
* the type is not repeated in the object test.
 +
* In the interface of the current type the 'variant' is removed. Indeed, it is not possible to call 'eat' on a COW instance with a parameter of type FOOD.
  
 
<e>
 
<e>
Line 133: Line 51:
 
end
 
end
 
</e>
 
</e>
 
 
<e>
 
<e>
 
class
 
class
Line 146: Line 63:
  
 
feature -- Eating
 
feature -- Eating
eat (f: variant like last) -- or eat (f: variant FOOD)
+
eat (f: variant like last) -- or eat (f: variant GRASS)
 
require else
 
require else
 
True
 
True
 
-- 'f' type = expected type. Here: GRASS
 
-- 'f' type = expected type. Here: GRASS
 
do
 
do
-- 'f' type = type of the previous definition. Here: FOOD
+
-- 'f' type = type of the first definition. Here: FOOD
if attached f as g then
+
if attached f as expected then
-- 'g' type = expected type. Here: GRASS
+
-- 'expected' type = expected type. Here: GRASS
last := g
+
last := expected
 
end
 
end
 
ensure then
 
ensure then
 
True
 
True
-- 'f' type = type of the previous definition. Here: FOOD
+
-- 'f' type = type of the first definition. Here: FOOD
 
end
 
end
  
Line 175: Line 92:
 
eat (f: variant like last)
 
eat (f: variant like last)
 
do
 
do
if attached f as safe then
+
if attached f as expected then
last := safe
+
last := expected
 
end
 
end
 
end
 
end
Line 197: Line 114:
  
 
'''example 3:''' contravariant redefinition
 
'''example 3:''' contravariant redefinition
 +
<e>
 +
note:
 +
description: eat all foods
 +
class
 +
MUTANT_COW
 +
redefine last end
 +
 +
feature -- Access
 +
last: FOOD
 +
 +
end
 +
</e>
 +
 +
=== Generic conformance ===
 +
Default: a generic is novariant
  
Z inherits of Y
+
If a genric must be variant (covariant or contravariant or both) then the formal generic must be prefixed with the 'variant' mark.
  
Y inherits of X
+
The compiler must ensure that the variant generic checks one next rule:
 +
* Generic used only on feature argument is contravariant.
 +
* Generic used only on request result or feature argument with variant typing is covariant.
 +
* Generic not used is both contravariant and covariant.
 +
 
 +
example:
 
<e>
 
<e>
class
+
deferred class
A
+
EXAMPLE [variant K, variant G]
 +
-- K is contravariant and G is covariant
  
 
feature -- Access
 
feature -- Access
something: variant Z
+
first: G
 
 
feature -- Other
+
item (i: K): G
do_something
+
deferred
do
+
-- 'something' type = ANY
+
if attached something as expected then
+
-- 'expected' type = feature result type. Here: Z
+
end
+
 
end
 
end
+
 
 
end
 
end
 
</e>
 
</e>
<e>
 
class
 
B
 
 
inherit
 
A
 
redefine something end
 
  
feature -- Access
+
Therefore the next code is valid:
something: variant Y
+
<e>
+
local
 +
a: EXAMPLE [INTEGER, COMPARABLE]; b: EXAMPLE [NUMERIC, STRING]
 +
do
 +
-- ...
 +
a := b
 
end
 
end
 
</e>
 
</e>
 +
 +
==== Agent conformance ====
 +
As explained for [[Usage-site variance]] the generic 'OPEN_ARGS' from ROUTINE, PROCEDURE, FUNCTION, PREDICATE must be contravariant.
 +
 
<e>
 
<e>
 
class
 
class
C
+
ROUTINE [BASE_TYPE, variant OPEN_ARGS -> detachable TUPLE create default_create end]
+
-- ...
inherit
+
end
B
+
</e>
redefine something, do_something end
+
  
feature -- Access
+
The generic 'OPEN_ARGS' is used on feature arguments, but also on request result.
something: X
+
 
 +
The class should probably be redesigned. Indeed if contravariant is allowed then there may be a new contravariant catcall on request result.
  
feature -- Other
+
In these classes there are only two requests using the generic as type:
do_something
+
<e>
do
+
operands: detachable OPEN_ARGS
-- 'something' type = X
+
 
end
+
empty_operands: OPEN_ARGS
end
+
do create Result ensure ... end
 +
</e>
 +
 
 +
The second request is not used internally and may be problematic for creation: How create a tuple of not self-initialized and attached types?
 +
The first is used in these features : 'target', 'is_equal', 'set_operands', 'copy', 'apply'
 +
 
 +
'is_equal', 'set_operands' and 'copy' rely on data model.
 +
'apply' and 'target' are more sensitive. Indeed the problem is when there is an opened target.
 +
 
 +
'apply' could be restricted for no opened arguments.
 +
<e>
 +
apply
 +
require
 +
no_operands: open_count = 0
 +
do
 +
call (Void)
 +
end
 +
</e>
 +
'target' could be modfied:
 +
<e>
 +
target: ANY
 +
require
 +
is_target_closed
 +
do
 +
-- ...
 +
end
 
</e>
 
</e>
  
 +
Or maybe it is better to separate opened target and closed target in two abstractions.
 +
 +
The redesign of agent classes is an opportunity to solve agent problems (see [[Minor-ECMA-problems]], [[Agents in SCOOP]]).
 +
 +
Another solution will be mentioned later.
 +
 +
Note:
 +
The generic 'RESULT_TYPE' of FUNCTION class is used only on request result. Then it is a covariant generic. It is an expected point.
 +
 +
=== Comparison with other solutions ===
 +
==== [[Detachable types]] (non-generic) ====
 +
The variant typing is not in conflict with the void-safe typing.
 +
 +
And more the object test is not needed.
 +
 +
==== [[Usage-site variance]] (generic) ====
 +
The variant typing is a supplier specification while usage-site variance is a client specification.
 +
 +
Another difference is the interface restriction of the usage-site variance. With the variant typing for generics the interface is fully aivailable.
 +
 +
=== Sub-conclusion ===
 +
The limited variant typing is reasonable and expressive. It limits Eiffel changes and solves all catcall problems.
 +
 +
The proposal reuses an existing keyword.
 +
 +
The addition in TYPE class for reflexivity and dynamic object test is little.
 +
Indeed two simple booleans "is_contravariant" and "is_covariant" for each generic is required.
 +
<e>
 +
generic_parameter_contravariant (i: INTEGER): BOOLEAN
 +
-- Is `i'-th generic parameter contravariant?
 +
 +
generic_parameter_covariant (i: INTEGER): BOOLEAN
 +
-- Is `i'-th generic parameter covariant?
 +
</e>
 +
 +
A possible critical could be the generic conformance restriction. Propositions are mentioned below.
 +
 +
 +
 +
== Extended variant typing ==
 
=== Generic conformance ===
 
=== Generic conformance ===
The variant typing can be used to change the default variance of generic type.
+
The variant mark is optional. The compiler infers the generic variance. It is a good point for backward compatibility.
  
 
* Generic used only on feature argument or request result with variant typing is contravariant.
 
* Generic used only on feature argument or request result with variant typing is contravariant.
* Generic used only on request result or feature argument with variant typing is covariant.
 
  
example: agents
+
==== Agent conformance ====
 
+
It is possible to declare 'operands' and 'empty_operands' as variant.
It is possible to decalre 'operands' and 'empty_operands' as variant.
+
 
<e>
 
<e>
 
operands: variant detachable OPEN_ARGS
 
operands: variant detachable OPEN_ARGS
Line 267: Line 264:
 
</e>
 
</e>
  
'apply' and 'target' should be write again. For example:
+
'apply' and 'target' should be wrote again. For example:
 
<e>
 
<e>
 
apply
 
apply
Line 282: Line 279:
  
 
=== Sub-conclusion ===
 
=== Sub-conclusion ===
This proposition reuses an existing keyword.
+
This part extend the proposition to enable a best backward compatibility and then a best transition.
The contravariant redefinition of request result can be remote for simplicity.
+
 
+
The lack of expressivity for generic variance can be reduced with a prefixed mark for a formal genric (see [[Default and explicit variance#Ensure the generic variance|just below]]).
+
 
+
== Ensure the generic variance ==
+
Sometimes the programmer wishes ensure a certain behavior.
+
For example for agents: it is expected 'OPEN_ARGS' be a contravariant generic.
+
 
+
A formal generic prefixed with the 'variant' keyword cannot be novariant.
+
It can be covariant or contravariant or both. This mark is optional (Backward compatibility and simplicity).
+
 
+
'''example:''' agents
+
<e>
+
class
+
ROUTINE [BASE_TYPE, variant OPEN_ARGS -> detachable TUPLE create default_create end]
+
-- ...
+
end
+
</e>
+
 
+
The compiler must check 'OPEN_ARGS' is not novariant.
+
  
== Discussions ==
+
== General discussions ==
 
=== Greater flexibility for generics ===
 
=== Greater flexibility for generics ===
 
A lot of generics could be novariant, encouraging to propose a solution to have a new flexibility, but safe.
 
A lot of generics could be novariant, encouraging to propose a solution to have a new flexibility, but safe.
Line 347: Line 324:
 
In V_CONTAINER class only two features should use the variant typing:
 
In V_CONTAINER class only two features should use the variant typing:
 
<e>
 
<e>
 +
new_cursor: V_ITERATOR [G]
 +
do ... end
 +
 
occurrences (v: variant G): INTEGER
 
occurrences (v: variant G): INTEGER
 
do
 
do
Line 361: Line 341:
 
it: like new_cursor
 
it: like new_cursor
 
do
 
do
it := new_cursor
+
-- G -> ANY then 'v' type = ANY
it.search_forth (v) -- {V_ITERATOR [G]}.search_forth (v: variant G)
+
it := new_cursor -- 'it' type = V_ITERATOR [ANY]
 +
it.search_forth (v)
 
Result := not it.after
 
Result := not it.after
 
ensure
 
ensure
Line 428: Line 409:
 
It passes all [[Catcall checkpoints]].
 
It passes all [[Catcall checkpoints]].
  
The default generic conformance gives a natural safe and flexible static typing.
+
The new generic conformance gives a natural safe and flexible static typing.
 
The variant typing enables to create adaptive interfaces keeping a safe static typing.
 
The variant typing enables to create adaptive interfaces keeping a safe static typing.
  
With a fine abstraction and the use of variant typing for generic, the genric conformance flexibility is little restricted. The contravariant for request result can then be discarded for simplicity.
+
With a fine abstraction and the use of variant typing for generics, the genric conformance flexibility is little restricted. The contravariant for request result can then be discarded for simplicity.
  
 
There is no interface restriction ([[Interval types]] or [[Usage-site variance]]). Class interfaces are fully available.
 
There is no interface restriction ([[Interval types]] or [[Usage-site variance]]). Class interfaces are fully available.

Revision as of 04:36, 11 May 2013

Research: This page describes research about Eiffel, not the actual language specification.

Introduction

In first the limited variant typing is exposed. It checks all catcall checkpoints. In the second part the mechanism is extended. It is less simple and explicit, but it enables a best transition.

Limited variant typing

What is the advantages of covariance compared to a novariant typing?

  • explicit and adaptative interface
  • One routine

Variant typing

  • A variant entity has the most restrictive type.
  • A variant antity requires a simple object test to use the entity with the expected type.

Examples are available in next sections.

Feature redefinition

  • Covariant redefinition of request result is allowed (as currently).
  • Covariant redefinition of feature argument requires a variant typing on redefined feature or first feature definition.

The most restrictive type for a variant type argument is the type of the first feature definition.

  • Contravariant redefinition of feature arguments is allowed, but the type must be the same than the first feature definition or a subtype.

The first rule is a stronger postcondition. The current semantic is not changed. The last rule is a new possibility in Eiffel, it is a weaker precondition.

example 1: covariant redefinition of feature argument with 'variant' typing on redefined feature

Note:

  • The object test is not needed.
  • the type is not repeated in the object test.
  • In the interface of the current type the 'variant' is removed. Indeed, it is not possible to call 'eat' on a COW instance with a parameter of type FOOD.
class
	ANIMAL
 
feature -- Access
	last: FOOD
 
feature -- Eating
	eat (f: like last)
		require
			True
		do
			last := f
		ensure
			True
		end
end
class
	COW
 
inherit
	ANIMAL
		redefine all end
 
feature -- Access
	last: GRASS
 
feature -- Eating
	eat (f: variant like last) -- or eat (f: variant GRASS)
		require else
			True
			-- 'f' type = expected type. Here: GRASS
		do
			-- 'f' type = type of the first definition. Here: FOOD
			if attached f as expected then
				-- 'expected' type = expected type. Here: GRASS
				last := expected
			end
		ensure then
			True
			-- 'f' type = type of the first definition. Here: FOOD
		end
 
end

example 2: covariant redefinition of feature argument with 'variant' typing on first feature definition.

class
	ANIMAL
 
feature -- Access
	last: FOOD
 
feature -- Eating
	eat (f: variant like last)
		do
			if attached f as expected then
				last := expected
			end
		end
end
class
	COW
 
inherit
	ANIMAL
		redefine last end
 
feature -- Access
	last: GRASS
 
end

example 3: contravariant redefinition

note:
	description: eat all foods
class
	MUTANT_COW
		redefine last end
 
feature -- Access
	last: FOOD
 
end

Generic conformance

Default: a generic is novariant

If a genric must be variant (covariant or contravariant or both) then the formal generic must be prefixed with the 'variant' mark.

The compiler must ensure that the variant generic checks one next rule:

  • Generic used only on feature argument is contravariant.
  • Generic used only on request result or feature argument with variant typing is covariant.
  • Generic not used is both contravariant and covariant.

example:

deferred class
	EXAMPLE [variant K, variant G]
		-- K is contravariant and G is covariant
 
feature -- Access
	first: G
 
	item (i: K): G
		deferred
		end
 
end

Therefore the next code is valid:

local
	a: EXAMPLE [INTEGER, COMPARABLE]; b: EXAMPLE [NUMERIC, STRING]
do
	-- ...
	a := b
end

Agent conformance

As explained for Usage-site variance the generic 'OPEN_ARGS' from ROUTINE, PROCEDURE, FUNCTION, PREDICATE must be contravariant.

class
	ROUTINE [BASE_TYPE, variant OPEN_ARGS -> detachable TUPLE create default_create end]
-- ...
end

The generic 'OPEN_ARGS' is used on feature arguments, but also on request result.

The class should probably be redesigned. Indeed if contravariant is allowed then there may be a new contravariant catcall on request result.

In these classes there are only two requests using the generic as type:

operands: detachable OPEN_ARGS
 
empty_operands: OPEN_ARGS
	do create Result ensure ... end

The second request is not used internally and may be problematic for creation: How create a tuple of not self-initialized and attached types? The first is used in these features : 'target', 'is_equal', 'set_operands', 'copy', 'apply'

'is_equal', 'set_operands' and 'copy' rely on data model. 'apply' and 'target' are more sensitive. Indeed the problem is when there is an opened target.

'apply' could be restricted for no opened arguments.

apply
	require
		no_operands: open_count = 0
	do
		call (Void)
	end

'target' could be modfied:

target: ANY
	require
		is_target_closed
	do
		-- ...
	end

Or maybe it is better to separate opened target and closed target in two abstractions.

The redesign of agent classes is an opportunity to solve agent problems (see Minor-ECMA-problems, Agents in SCOOP).

Another solution will be mentioned later.

Note: The generic 'RESULT_TYPE' of FUNCTION class is used only on request result. Then it is a covariant generic. It is an expected point.

Comparison with other solutions

Detachable types (non-generic)

The variant typing is not in conflict with the void-safe typing.

And more the object test is not needed.

Usage-site variance (generic)

The variant typing is a supplier specification while usage-site variance is a client specification.

Another difference is the interface restriction of the usage-site variance. With the variant typing for generics the interface is fully aivailable.

Sub-conclusion

The limited variant typing is reasonable and expressive. It limits Eiffel changes and solves all catcall problems.

The proposal reuses an existing keyword.

The addition in TYPE class for reflexivity and dynamic object test is little. Indeed two simple booleans "is_contravariant" and "is_covariant" for each generic is required.

generic_parameter_contravariant (i: INTEGER): BOOLEAN
	-- Is `i'-th generic parameter contravariant?
 
generic_parameter_covariant (i: INTEGER): BOOLEAN
	-- Is `i'-th generic parameter covariant?

A possible critical could be the generic conformance restriction. Propositions are mentioned below.


Extended variant typing

Generic conformance

The variant mark is optional. The compiler infers the generic variance. It is a good point for backward compatibility.

  • Generic used only on feature argument or request result with variant typing is contravariant.

Agent conformance

It is possible to declare 'operands' and 'empty_operands' as variant.

operands: variant detachable OPEN_ARGS
 
empty_operands: variant OPEN_ARGS
	do create Result ensure ... end

'apply' and 'target' should be wrote again. For example:

apply
	do
		-- 'operands' type = constrained inheritance. Here: detachable TUPLE
		if attached operands as args then
			-- 'operands' type = request result type. Here: OPEN_ARGS
			call (args)
		else
			call (Void)
		end
	end

Sub-conclusion

This part extend the proposition to enable a best backward compatibility and then a best transition.

General discussions

Greater flexibility for generics

A lot of generics could be novariant, encouraging to propose a solution to have a new flexibility, but safe.

Wildcard generics

The request result type is the constrained inheritance type. And the type of the feature argument is (attached) NONE. The new semantic of 'Void' is considered: Void is not a NONE instance.

local
	a: ARRAY [?]; b: ARRAY [STRING]
	o: ANY
do
	-- ...
	a := b
	o := a.item (1)
	a.put ("try") -- invalid call. The type expected is NONE.
end

However the wildcard generics will be used on request result or feature argument. A more power and elegent solution could be the parametrized routines.

Parametrized routines

do_something [G] (a: ARRAY [G]): G
	require
		a.count >= 1
	do
		Result := a.item (1)
	end

Right abstraction

The wildcard generics and the parametrized routines introduce new constructs for Eiffel. Is there another solution avoiding this?

With a right abstraction it is possible to have flexible classes. It is comparable to the imuutable cocncept.

example: V_CONTAINER class of Eiffel Base 2 To obtain the genric covariance behavior it is necessary to have: - V_ITERATOR must have a covariant generic. - An immutable abstraction of tuple IMMUTABLE_TUPLE should be wrote.

In V_CONTAINER class only two features should use the variant typing:

new_cursor: V_ITERATOR [G]
	do ... end
 
occurrences (v: variant G): INTEGER
		do
			-- G -> ANY then 'v' type = ANY
			across Current as it loop
				if it.item = v then
					Result := Result + 1
				end
			end
		end
 
has (v: variant G)
	local
		it: like new_cursor
	do
		-- G -> ANY then 'v' type = ANY
		it := new_cursor -- 'it' type = V_ITERATOR [ANY]
		it.search_forth (v)
		Result := not it.after
	ensure
		occurrences (v) = 1	
	end

In V_ITERATOR only two features should use the variant typing without object test!

With these changes the next code is valid:

local
	a: V_CONTAINER [ANY]; b: V_CONTAINER [STRING]
do
	a := b
 
end

Sub-conclusion

With a right abstraction and a smart use of variant typing for generics, it is possible to obtain a greater flexibility keeping a fully aivailable interface.

Export status restrictions

Since the ECMA Eiffel Standard forbids the export restriction with conforming inheritance, it is not a problem. However, the semantic can be changed to enable this restriction on conforming inheritance.

Restrict exportation should not cause a catcall. The mechanism could be used just to change the class interface.

deferred class
	ANIMAL
feature
	is_vegetarian: BOOLEAN
		deferred end
end
class
	COW
inherit
	ANIMAL
		export {NONE}
			is_vegetarian
		end
feature {NONE}
	is_vegetarian: BOOLEAN = True
end
local
	an_animal: ANIMAL; a_cow: COW
	b: BOOLEAN
do
	create a_cow
	b := a_cow.is_vegetarian -- invalid call
 
	an_animal := a_cow
	b := an_animal .is_vegetarian -- valid call
end

The class interface is more simple and readable.

Conclusion

The proposition uses no new keyword and solves the catcall problem. It passes all Catcall checkpoints.

The new generic conformance gives a natural safe and flexible static typing. The variant typing enables to create adaptive interfaces keeping a safe static typing.

With a fine abstraction and the use of variant typing for generics, the genric conformance flexibility is little restricted. The contravariant for request result can then be discarded for simplicity.

There is no interface restriction (Interval types or Usage-site variance). Class interfaces are fully available.