docs/language/informal/covariant-from-class.md - sdk.git - Git at Google

 # Informal Specification: Parameters that are Covariant due to Class Type Parameters

 **Owner**: eernst@

 **Status**: This document is now background material.
 For normative text, please consult the language specification.

 **Version**: 0.6 (2018-06-01)


 ## Summary

 This document is an informal specification which specifies how to determine
 the reified type of a tear-off where one or more parameters has a type
 annotation in which a formal type parameter of the enclosing class occurs
 in a covariant position. This feature has no effect in Dart 1, it is only
 concerned with Dart 2.


 ## Motivation

 The main topic here is variance, so we will briefly introduce that concept.

 Consider the situation where a type is specified as an expression that
 contains another type as a subexpression. For instance, `List<int>`
 contains `int` as a subexpression. We may then consider `List<...>` as a
 function, and `int` as an argument which is passed to that function. With
 that, covariance is the property that this function is increasing, and
 contravariance is the property that it is decreasing, using the subtype
 relation for comparisons.

 Generic classes in Dart are covariant in all their arguments. For example
 `List<E>` is covariant in `E`. This then means that `List<...>` is an
 increasing function, i.e., whenever `S` is a subtype of `T`, `List<S>`
 is a subtype of `List<T>`.

 The subtype rule for function types in Dart 1 is different from the one in
 strong mode and in the upcoming Dart 2. This difference is the main fact
 that motivates the feature described in this document.

 Concretely, the subtype rule for function types allows for covariant return
 types in all cases. For instance, assuming that two functions `f` and `g`
 have identical parameter types, the type of `f` will always be a subtype of
 the type of `g` if `f` returns `int` and `g` returns `num`.

 This is not true for parameter types. In Dart 1, the function type subtype
 rule allows for covariant parameter types as well as contravariant ones,
 but strong mode and the upcoming Dart 2 require contravariance for
 parameter types. For instance, we have the following cases (using `void`
 for the return type, because the return type is uninteresting, it should
 just be the same everywhere):

 ```dart
 typedef void F(num n);

 void f1(Object o) {}
 void f2(num n) {}
 void f3(int i) {}

 main() {
   F myF;
   myF = f1;  // Contravariance: Succeeds in Dart 1, and in strong mode.
   myF = f2;  // Same type: Always succeeds.
   myF = f3;  // Covariance: Succeeds in Dart 1, but fails in strong mode.
 }
 ```

 In all cases, the variance is concerned with the relationship between the
 type of the parameter for `myF` and the type of the parameter for the
 function which is assigned to `myF`. Since Dart 1 subtyping makes both `f1`
 and `f3` subtypes of the type of `myF`, all assignments succeed at run time
 (and static analysis proceeds without warnings). In strong mode and Dart 2,
 `f3` does not have a subtype of the type of `myF`, so this is considered as
 a downcast at compile time, and it fails at runtime.

 Contravariance is the sound rule that most languages use, so this means
 that function calls in strong mode and in Dart 2 are subject to more tight
 type checking, and some run-time errors cannot occur.

 However, covariant parameter types can be quite natural and convenient,
 they just impose an obligation on developers to use ad-hoc reasoning in
 order to avoid the potential type errors at run time. The
 [covariant overrides](https://github.com/dart-lang/sdk/blob/master/docs/language/informal/covariant-overrides.md)
 feature was added exactly for this purpose: When developers want to use
 unsound covariance, they can get it by requesting it explicitly. In the
 (vast majority of) cases where the sound and more strict contravariant rule
 fits the intended design, there will be no such request, and parameter type
 covariance (which would then presumably only arise by mistake) will be
 flagged as a type error.

 In order to preserve a fundamental soundness property of Dart, the reified
 type of tear-offs of methods has parameter type `Object` for every
 parameter whose type is covariant. The desired property is that every
 expression with static type `T` must evaluate to a value whose dynamic type
 `S` which is a subtype of `T`. Here is an example why it would not work to
 reify the declared parameter type directly:

 ```dart
 // Going by the OLD RULES, showing why we need to introduce new ones.

 typedef void F(num n);

 class A {
   // The reified parameter type is `num`, directly as declared.
   void f(covariant num n) {}
 }

 class B extends A {
   // The reified parameter type is `int`, directly as declared.
   void f(int i) {}
 }

 main() {
   A a = new B();
   F myF = a.f; // Statically safe, yet fails at run time!
 }
 ```

 The problem is that `a.f` has static type `void Function(num)`, and if the
 reified type at run time is `void Function(int)` then `a.f` is an expression
 whose value at run time does _not_ conform to the statically known type.

 Even worse, there is no statically known type annotation that we can use in
 the declaration of `myF` which will make it safe&mdash;the value of `a`
 could be an instance of some other class `C` where the parameter type is
 `double`, and in general we cannot statically specify a function type where
 the parameter type is a subtype of the actual parameter type at runtime (as
 required for the initialization to succeed).

 *We could use the bottom type as the argument type, `void Function(Null)`, but
 that makes all invocations unsafe (except `myF(null)`). We believe that it is
 more useful to preserve the information that "it must be some kind of number",
 even though not all kinds of numbers will work. With `Null`, we just communicate
 that all invocations are unsafe, with no hints at all about which ones would be
 less unsafe than others.*

 We do not want any such expressions where the value is not a subtype of the
 statically known type, and hence the reified type of `a.f` is `void
 Function(Object)`. In general, the type of each covariant parameter is reified
 as `Object`. In the example, this is how it works:

 ```dart
 typedef void F(num n);

 class A {
   // The reified parameter type is `Object` because `n` is covariant.
   void f(covariant num n) {}
 }

 class B extends A {
   // The reified parameter type is `Object` because `i` is covariant.
   void f(int i) {}
 }

 main() {
   A a = new B();
   F myF = a.f; // Statically safe, and succeeds at runtime.
 }
 ```

 *Note that an invocation of `myF` can be statically safe and yet fail at
 runtime, e.g., `myF(3.1)`, but this is exactly the same situation as with
 the torn-off method: `a.f(3.1)` is also considered statically safe, and yet
 it will fail at runtime.*

 The purpose of this document is to cover one extra type of situation where
 the same typing situation arises.

 Parameters can have a covariant type because they are or contain a formal
 type parameter of an enclosing generic class. Here is an example using the
 core class `List` (which underscores that it is a common phenomenon, but
 any generic class would do). It illustrates why we need to change the
 reified type of tear-offs also with parameters that are covariant due to
 class covariance:

 ```dart
 // Going by the OLD RULES, showing why we need to introduce new ones.

 // Here is the small part of the core List class that we need here.
 abstract class List<E> ... {
   // The reified type is `void Function(E)` in all modes, as declared.
   void add(E value);
   // The reified type is `void Function(Iterable<E>)` in all modes, as declared.
   void addAll(Iterable<E> iterable);
   ...
 }

 typedef void F(num n);
 typedef void G(Iterable<num> n);

 main() {
   List<num> xs = <int>[1, 2];
   F myF = xs.add;    // Statically safe, yet fails at run time
                      // in strong mode and Dart 2.
   G myG = xs.addAll; // Same situation as with myF.
 }
 ```

 The example illustrates that the exact same typing situation arises in the
 following two cases:

 - A covariant parameter type is induced by an overriding method declaration
   (example: `int i` in `B.f`).
 - A covariant parameter type is induced by the use of a formal type
   parameter of the enclosing generic class in a covariant position in the
   parameter type declaration (example: `E value` and `Iterable<E> iterable`
   in `List.add` resp. `List.addAll`).

 This document specifies how to preserve the above mentioned expression
 soundness property of Dart, based on a modified rule for how to reify
 parameter types of tear-offs. Here is how it works with the new rules
 specified in this document:

 ```dart
 abstract class List<E> ... {
   // The reified type is `void Function(Object)` in all modes.
   void add(E value);
   // The reified type is `void Function(Object)` in all modes.
   void addAll(Iterable<E> iterable);
   ...
 }

 typedef void F(num n);
 typedef void G(Iterable<num> n);

 main() {
   List<num> xs = <int>[1, 2];
   F myF = xs.add;    // Statically safe, and succeeds at run time.
   G myG = xs.addAll; // Same situation as with myF.
 }
 ```


 ## Feature specification


 ### Syntax

 The grammar remains unchanged.


 #### Static analysis

 The static type of a property extraction remains unchanged.

 *The static type of a torn-off method is taken directly from the statically
 known declaration of that method, substituting actual type arguments for
 formal type parameters as usual. For instance, the static type of
 `xs.addAll` is `void Function (Iterable<num>)` when the static type of `xs` is
 `List<num>`. Note that this is significant because the reified types of some
 torn-off methods will indeed change with the introduction of this feature.*

 When we say that a parameter is **covariant by modifier**, we are referring
 to the definition of being a covariant parameter which is given in
 [covariant overrides](https://github.com/dart-lang/sdk/blob/master/docs/language/informal/covariant-overrides.md).

 *When a parameter _p_ is covariant by modifier, there will necessarily be a
 declaration of a formal parameter _p1_ (which may be the same as _p_, or it
 may be different) which contains the built-in identifier `covariant`.*

 *We need to introduce a new kind of covariant parameters, in addition to the
 ones that are covariant by modifier. To do that, we also need to refer to
 the variance of each occurrence of a type variable in a type, which is
 specified in the language specification.*

 Consider a class _T_ which is generic or has a generic supertype (directly
 or indirectly). Let _S_ be said generic class. Assume that there is a
 declaration of a method, setter, or operator `m` in _S_, that `X` is a
 formal type parameter declared by _S_, and that said declaration of `m` has
 a formal parameter `x` wherein `X` occurs covariantly or invariantly. In
 this situation we say that the parameter `x` is **covariant by class
 covariance**.

 *This means that the type annotation of the given parameter may actually be
 covariant in the relevant type parameter, or it may vary among types that
 have no subtype relationship to each other. The parameter will be called
 'covariant' in both cases, because the situation where it is actually
 covariant is expected to be much more common than the situation where it
 varies among unrelated types.*

 When checking whether a given instance method declaration _D1_ is a correct
 override of another instance method declaration _D2_, it is ignored whether or
 not a formal parameter in _D1_ or _D2_ is covariant by class covariance.

 *This differs from the treatment of parameters which are covariant by modifier,
 where an overriding parameter type must be a subtype or a supertype of each
 overridden parameter type. In practice this means a parameter which is
 covariant by modifier may be specialized covariantly without limit, but a
 parameter which is covariant by class covariance must be overridden by a
 parameter with the same type or a supertype thereof, and it is only that type
 itself which "is covariant" (in the sense that clients know an upper bound
 _T_ statically, and for the actual type _S_ at run time it is only known that
 _S <: T_). Here is an example:*

 ```dart
 abstract class C<X> {
   void f1(X x);
   void f2(X x);
   void f3(covariant num x);
   void f4(X x);
   void f5(covariant X x);
 }

 abstract class D extends C<num> {
   void f1(num n); // OK
   void f2(int i); // Error: `num <: int` required, but not true.
   void f3(int i); // OK: covariant by modifier (only).
   void f4(covariant int i); // OK: covariant by modifier (and class).
   void f5(int i); // OK: covariant by modifier (and class).
 }
 ```


 #### Dynamic semantics

 In the following, the phrase _covariant parameter_ denotes either a parameter
 which is covariant by modifier, or a parameter which is covariant by class
 covariance.

 *We could have used 'covariant by class covariance' throughout, but for overall
 simplicity we make it explicit that the treatment of both kinds of covariant
 parameters is identical in the dynamic semantics.*

 The reified type for a function _f_ obtained by a closurizing property
 extraction on an instance method, setter, or operator is determined as
 follows:

 Let `m` be the name of the method, operator, or setter which is being
 closurized, let _T_ be the dynamic type of the receiver, and let _D_ be the
 declaration of `m` in _T_ or inherited by _T_ which is being extracted.

 The reified return type of _f_ the is the static return type of _D_. For
 each parameter `p` declared in _D_ which is not covariant, the part in the
 dynamic type of _f_ which corresponds to `p` is the static type of `p` in
 _D_. For each covariant parameter `q`, the part in the dynamic type of _f_
 which corresponds to `q` is `Object`.

 *The occurrences of type parameters in the types of non-covariant
 parameters (note that those occurrences must be in a non-covariant position
 in the parameter type) are used as-is. For instance, `<String>[].asMap()`
 will have the reified type `Map<int, String> Function()`.*

 The dynamic checks associated with invocation of such a function are still
 needed, and they are unchanged.

 *That is, a dynamic error occurs if a method with a covariant parameter p
 is invoked, and the actual argument value bound to p has a run-time type
 which is not a subtype of the type declared for p.*


 ## Alternatives

 The "erasure" of the reified parameter type for each covariant parameter to
 `Object` may seem aggressive.

 In particular, it ignores upper bounds on the formal type parameter which gives
 rise to the covariance by class covariance, and it ignores the structure of
 the type where that formal type parameter is used. Here are two examples:

 ```dart
 class C<X extends num> {
   void foo(X x) {}
   void bar(List<X> xs) {}
 }
 ```

 With this declaration, the reified type of `new C<int>().foo` will be `void
 Function(Object)`, even though it would have been possible to use the type `void
 Function(num)` based on the upper bound of `X`, and still preserve the earlier
 mentioned expression soundness. This is because all supertypes of the dynamic
 type of the receiver that declare `foo` have an argument type for it which is a
 subtype of `num`.

 Similarly, the reified type of `new C<int>().bar` will be `void
 Function(Object)`, even though it would have been possible to use the type `void
 Function(List<num>)`.

 Note that the reified type is independent of the static type of the receiver, so
 it does not matter that we consider `new C<int>()` directly, rather than using
 an intermediate variable whose type annotation is some supertype, e.g.,
 `C<num>`.

 In the first example, `foo`, there is a loss of information because we are
 (dynamically) allowed to assign the function to a variable of type `void
 Function(Object)`. Even worse, we may assign it to a variable of type `void
 Function(String)`, because `void Function(Object)` (that is, the actual type
 that the function reports to have) is a subtype of `void Function(String)`. In
 that situation, every statically safe invocation will fail, because there are no
 values of type `String` which will satisfy the dynamic check in the function
 itself, which requires an argument of type `int` (except `null`, of course, but
 this is rarely sufficient to make the function useful).

 In the second example, `bar`, the same phenomenon is extended a little, because
 we may assign the given torn-off function to a variable of type `void
 Function(String)`, in addition to more reasonable ones like `void
 Function(Object) `, `void Function(Iterable<Object>)`, and `void
 Function(Iterable<int>)`.

 It is certainly possible to specify a more "tight" reified type like the ones
 mentioned above. In order to do this, we would need the least upper bound of all
 the statically known types in all supertypes of the dynamic type of the
 receiver. This would involve a least upper bound operation on a set of types,
 and it would involve an instantiate-to-bounds operation on the type parameters.

 The main problem with this approach is that some declarations do not allow for
 computation of a finite type which is the least upper bound of all possible
 instantiations, so we cannot instantiate-to-bound:

 ```dart
 // There is no finite type `T` such that all possible values for `X`
 // and no other types are subtypes of `T`.
 class D<X extends D<X>> {}
 ```

 Similarly, some finite sets of types do not have a denotable least upper bound:

 ```dart
 class I {}
 class J {}

 class A implements I, J {}
 class B implements I, J {}
 ```

 In this case both of `A` and `B` have the two immediate superinterfaces `I` and
 `J`, and there is no single type (that we can express in Dart) which is the
 least of all the supertypes of `A` and `B`.

 So in some cases we will have to error out when we compute the reified type of a
 tear-off of a given method, unless we introduce intersection types and infinite
 types, or unless we find some other way around this difficulty.

 On the other hand, it should be noted that the common usage of these torn-off
 functions would be guided by the statically known types, which do have the
 potential to keep them "within a safe domain".

 Here is an example:

 ```dart
 main() {
   List<int> xs = <int>[];
   void Function(int) f1 = xs.add; // Same type statically, OK at runtime.
   void Function(num) f2 = xs.add; // Statically a downcast, can warn, OK at runtime.
   void Function(Object) f3 = xs.add; // A downcast, can warn, OK at runtime.
   void Function(String) f4 = xs.add; // An unrelated type, error in strong mode.

   List<num> ys = xs; // "Forget part of the type".
   void Function(int) f5 = ys.add; // Statically an upcast, OK at runtime.
   void Function(num) f6 = ys.add; // Statically same type, OK at runtime.
   void Function(Object) f7 = ys.add; // Statically a downcast, OK at runtime.
   void Function(String) f8 = ys.add; // An unrelated type, error in strong mode.

   List<Object> zs = ys;
   void Function(int) f9 = zs.add; // Statically an upcast, OK at runtime.
   void Function(num) fa = zs.add; // Statically an upcast, OK at runtime.
   void Function(Object) fb = zs.add; // Statically same type, OK at runtime.
   void Function(String) fc = zs.add; // Finally we can go wrong silently!
 }
 ```

 In other words, the static typing helps programmers to maintain the same level
 of knowledge (say, "this is a list of `num`") consistently, even though it is
 consistently incomplete ("it's actually a list of `int`"), and this helps a lot
 in avoiding those crazy assignments (to `List<String>`) where almost all method
 invocations will go wrong.


 ## Updates

 *   Jun 1st 2018, version 0.6: Removed specification of variance, for which
     the normative text is now part of the language specification. Adjusted
     the wording to fit the slightly different definitions of variance given
     there. The meaning of this feature specification has not changed.

 *   Feb 1st 2018, version 0.5: Added specification of override checks for
     parameters which are covariant from class.

 *   Nov 24th 2017, version 0.4: Modified the definition of what it takes to be
     a covariant parameter: Some cases were previously incorrectly omitted.

 *   Nov 11th 2017, no version number specified: Clarified examples.

 *   Apr 21st 2017, no version number specified: Some typos corrected.

 *   Feb 16th 2017, no version number specified: Initial version.
	# Informal Specification: Parameters that are Covariant due to Class Type Parameters

	Owner: eernst@

	Status: This document is now background material.
	For normative text, please consult the language specification.

	Version: 0.6 (2018-06-01)


	## Summary

	This document is an informal specification which specifies how to determine
	the reified type of a tear-off where one or more parameters has a type
	annotation in which a formal type parameter of the enclosing class occurs
	in a covariant position. This feature has no effect in Dart 1, it is only
	concerned with Dart 2.


	## Motivation

	The main topic here is variance, so we will briefly introduce that concept.

	Consider the situation where a type is specified as an expression that
	contains another type as a subexpression. For instance, `List<int>`
	contains `int` as a subexpression. We may then consider `List<...>` as a
	function, and `int` as an argument which is passed to that function. With
	that, covariance is the property that this function is increasing, and
	contravariance is the property that it is decreasing, using the subtype
	relation for comparisons.

	Generic classes in Dart are covariant in all their arguments. For example
	`List<E>` is covariant in `E`. This then means that `List<...>` is an
	increasing function, i.e., whenever `S` is a subtype of `T`, `List<S>`
	is a subtype of `List<T>`.

	The subtype rule for function types in Dart 1 is different from the one in
	strong mode and in the upcoming Dart 2. This difference is the main fact
	that motivates the feature described in this document.

	Concretely, the subtype rule for function types allows for covariant return
	types in all cases. For instance, assuming that two functions `f` and `g`
	have identical parameter types, the type of `f` will always be a subtype of
	the type of `g` if `f` returns `int` and `g` returns `num`.

	This is not true for parameter types. In Dart 1, the function type subtype
	rule allows for covariant parameter types as well as contravariant ones,
	but strong mode and the upcoming Dart 2 require contravariance for
	parameter types. For instance, we have the following cases (using `void`
	for the return type, because the return type is uninteresting, it should
	just be the same everywhere):

	```dart
	typedef void F(num n);

	void f1(Object o) {}
	void f2(num n) {}
	void f3(int i) {}

	main() {
	F myF;
	myF = f1; // Contravariance: Succeeds in Dart 1, and in strong mode.
	myF = f2; // Same type: Always succeeds.
	myF = f3; // Covariance: Succeeds in Dart 1, but fails in strong mode.
	}
	```

	In all cases, the variance is concerned with the relationship between the
	type of the parameter for `myF` and the type of the parameter for the
	function which is assigned to `myF`. Since Dart 1 subtyping makes both `f1`
	and `f3` subtypes of the type of `myF`, all assignments succeed at run time
	(and static analysis proceeds without warnings). In strong mode and Dart 2,
	`f3` does not have a subtype of the type of `myF`, so this is considered as
	a downcast at compile time, and it fails at runtime.

	Contravariance is the sound rule that most languages use, so this means
	that function calls in strong mode and in Dart 2 are subject to more tight
	type checking, and some run-time errors cannot occur.

	However, covariant parameter types can be quite natural and convenient,
	they just impose an obligation on developers to use ad-hoc reasoning in
	order to avoid the potential type errors at run time. The
	[covariant overrides](https://github.com/dart-lang/sdk/blob/master/docs/language/informal/covariant-overrides.md)
	feature was added exactly for this purpose: When developers want to use
	unsound covariance, they can get it by requesting it explicitly. In the
	(vast majority of) cases where the sound and more strict contravariant rule
	fits the intended design, there will be no such request, and parameter type
	covariance (which would then presumably only arise by mistake) will be
	flagged as a type error.

	In order to preserve a fundamental soundness property of Dart, the reified
	type of tear-offs of methods has parameter type `Object` for every
	parameter whose type is covariant. The desired property is that every
	expression with static type `T` must evaluate to a value whose dynamic type
	`S` which is a subtype of `T`. Here is an example why it would not work to
	reify the declared parameter type directly:

	```dart
	// Going by the OLD RULES, showing why we need to introduce new ones.

	typedef void F(num n);

	class A {
	// The reified parameter type is `num`, directly as declared.
	void f(covariant num n) {}
	}

	class B extends A {
	// The reified parameter type is `int`, directly as declared.
	void f(int i) {}
	}

	main() {
	A a = new B();
	F myF = a.f; // Statically safe, yet fails at run time!
	}
	```

	The problem is that `a.f` has static type `void Function(num)`, and if the
	reified type at run time is `void Function(int)` then `a.f` is an expression
	whose value at run time does _not_ conform to the statically known type.

	Even worse, there is no statically known type annotation that we can use in
	the declaration of `myF` which will make it safe—the value of `a`
	could be an instance of some other class `C` where the parameter type is
	`double`, and in general we cannot statically specify a function type where
	the parameter type is a subtype of the actual parameter type at runtime (as
	required for the initialization to succeed).

	*We could use the bottom type as the argument type, `void Function(Null)`, but
	that makes all invocations unsafe (except `myF(null)`). We believe that it is
	more useful to preserve the information that "it must be some kind of number",
	even though not all kinds of numbers will work. With `Null`, we just communicate
	that all invocations are unsafe, with no hints at all about which ones would be
	less unsafe than others.*

	We do not want any such expressions where the value is not a subtype of the
	statically known type, and hence the reified type of `a.f` is `void
	Function(Object)`. In general, the type of each covariant parameter is reified
	as `Object`. In the example, this is how it works:

	```dart
	typedef void F(num n);

	class A {
	// The reified parameter type is `Object` because `n` is covariant.
	void f(covariant num n) {}
	}

	class B extends A {
	// The reified parameter type is `Object` because `i` is covariant.
	void f(int i) {}
	}

	main() {
	A a = new B();
	F myF = a.f; // Statically safe, and succeeds at runtime.
	}
	```

	*Note that an invocation of `myF` can be statically safe and yet fail at
	runtime, e.g., `myF(3.1)`, but this is exactly the same situation as with
	the torn-off method: `a.f(3.1)` is also considered statically safe, and yet
	it will fail at runtime.*

	The purpose of this document is to cover one extra type of situation where
	the same typing situation arises.

	Parameters can have a covariant type because they are or contain a formal
	type parameter of an enclosing generic class. Here is an example using the
	core class `List` (which underscores that it is a common phenomenon, but
	any generic class would do). It illustrates why we need to change the
	reified type of tear-offs also with parameters that are covariant due to
	class covariance:

	```dart
	// Going by the OLD RULES, showing why we need to introduce new ones.

	// Here is the small part of the core List class that we need here.
	abstract class List<E> ... {
	// The reified type is `void Function(E)` in all modes, as declared.
	void add(E value);
	// The reified type is `void Function(Iterable<E>)` in all modes, as declared.
	void addAll(Iterable<E> iterable);
	...
	}

	typedef void F(num n);
	typedef void G(Iterable<num> n);

	main() {
	List<num> xs = <int>[1, 2];
	F myF = xs.add; // Statically safe, yet fails at run time
	// in strong mode and Dart 2.
	G myG = xs.addAll; // Same situation as with myF.
	}
	```

	The example illustrates that the exact same typing situation arises in the
	following two cases:

	- A covariant parameter type is induced by an overriding method declaration
	(example: `int i` in `B.f`).
	- A covariant parameter type is induced by the use of a formal type
	parameter of the enclosing generic class in a covariant position in the
	parameter type declaration (example: `E value` and `Iterable<E> iterable`
	in `List.add` resp. `List.addAll`).

	This document specifies how to preserve the above mentioned expression
	soundness property of Dart, based on a modified rule for how to reify
	parameter types of tear-offs. Here is how it works with the new rules
	specified in this document:

	```dart
	abstract class List<E> ... {
	// The reified type is `void Function(Object)` in all modes.
	void add(E value);
	// The reified type is `void Function(Object)` in all modes.
	void addAll(Iterable<E> iterable);
	...
	}

	typedef void F(num n);
	typedef void G(Iterable<num> n);

	main() {
	List<num> xs = <int>[1, 2];
	F myF = xs.add; // Statically safe, and succeeds at run time.
	G myG = xs.addAll; // Same situation as with myF.
	}
	```


	## Feature specification


	### Syntax

	The grammar remains unchanged.


	#### Static analysis

	The static type of a property extraction remains unchanged.

	*The static type of a torn-off method is taken directly from the statically
	known declaration of that method, substituting actual type arguments for
	formal type parameters as usual. For instance, the static type of
	`xs.addAll` is `void Function (Iterable<num>)` when the static type of `xs` is
	`List<num>`. Note that this is significant because the reified types of some
	torn-off methods will indeed change with the introduction of this feature.*

	When we say that a parameter is covariant by modifier, we are referring
	to the definition of being a covariant parameter which is given in
	[covariant overrides](https://github.com/dart-lang/sdk/blob/master/docs/language/informal/covariant-overrides.md).

	*When a parameter _p_ is covariant by modifier, there will necessarily be a
	declaration of a formal parameter _p1_ (which may be the same as _p_, or it
	may be different) which contains the built-in identifier `covariant`.*

	*We need to introduce a new kind of covariant parameters, in addition to the
	ones that are covariant by modifier. To do that, we also need to refer to
	the variance of each occurrence of a type variable in a type, which is
	specified in the language specification.*

	Consider a class _T_ which is generic or has a generic supertype (directly
	or indirectly). Let _S_ be said generic class. Assume that there is a
	declaration of a method, setter, or operator `m` in _S_, that `X` is a
	formal type parameter declared by _S_, and that said declaration of `m` has
	a formal parameter `x` wherein `X` occurs covariantly or invariantly. In
	this situation we say that the parameter `x` is **covariant by class
	covariance**.

	*This means that the type annotation of the given parameter may actually be
	covariant in the relevant type parameter, or it may vary among types that
	have no subtype relationship to each other. The parameter will be called
	'covariant' in both cases, because the situation where it is actually
	covariant is expected to be much more common than the situation where it
	varies among unrelated types.*

	When checking whether a given instance method declaration _D1_ is a correct
	override of another instance method declaration _D2_, it is ignored whether or
	not a formal parameter in _D1_ or _D2_ is covariant by class covariance.

	*This differs from the treatment of parameters which are covariant by modifier,
	where an overriding parameter type must be a subtype or a supertype of each
	overridden parameter type. In practice this means a parameter which is
	covariant by modifier may be specialized covariantly without limit, but a
	parameter which is covariant by class covariance must be overridden by a
	parameter with the same type or a supertype thereof, and it is only that type
	itself which "is covariant" (in the sense that clients know an upper bound
	_T_ statically, and for the actual type _S_ at run time it is only known that
	_S <: T_). Here is an example:*

	```dart
	abstract class C<X> {
	void f1(X x);
	void f2(X x);
	void f3(covariant num x);
	void f4(X x);
	void f5(covariant X x);
	}

	abstract class D extends C<num> {
	void f1(num n); // OK
	void f2(int i); // Error: `num <: int` required, but not true.
	void f3(int i); // OK: covariant by modifier (only).
	void f4(covariant int i); // OK: covariant by modifier (and class).
	void f5(int i); // OK: covariant by modifier (and class).
	}
	```


	#### Dynamic semantics

	In the following, the phrase _covariant parameter_ denotes either a parameter
	which is covariant by modifier, or a parameter which is covariant by class
	covariance.

	*We could have used 'covariant by class covariance' throughout, but for overall
	simplicity we make it explicit that the treatment of both kinds of covariant
	parameters is identical in the dynamic semantics.*

	The reified type for a function _f_ obtained by a closurizing property
	extraction on an instance method, setter, or operator is determined as
	follows:

	Let `m` be the name of the method, operator, or setter which is being
	closurized, let _T_ be the dynamic type of the receiver, and let _D_ be the
	declaration of `m` in _T_ or inherited by _T_ which is being extracted.

	The reified return type of _f_ the is the static return type of _D_. For
	each parameter `p` declared in _D_ which is not covariant, the part in the
	dynamic type of _f_ which corresponds to `p` is the static type of `p` in
	_D_. For each covariant parameter `q`, the part in the dynamic type of _f_
	which corresponds to `q` is `Object`.

	*The occurrences of type parameters in the types of non-covariant
	parameters (note that those occurrences must be in a non-covariant position
	in the parameter type) are used as-is. For instance, `<String>[].asMap()`
	will have the reified type `Map<int, String> Function()`.*

	The dynamic checks associated with invocation of such a function are still
	needed, and they are unchanged.

	*That is, a dynamic error occurs if a method with a covariant parameter p
	is invoked, and the actual argument value bound to p has a run-time type
	which is not a subtype of the type declared for p.*


	## Alternatives

	The "erasure" of the reified parameter type for each covariant parameter to
	`Object` may seem aggressive.

	In particular, it ignores upper bounds on the formal type parameter which gives
	rise to the covariance by class covariance, and it ignores the structure of
	the type where that formal type parameter is used. Here are two examples:

	```dart
	class C<X extends num> {
	void foo(X x) {}
	void bar(List<X> xs) {}
	}
	```

	With this declaration, the reified type of `new C<int>().foo` will be `void
	Function(Object)`, even though it would have been possible to use the type `void
	Function(num)` based on the upper bound of `X`, and still preserve the earlier
	mentioned expression soundness. This is because all supertypes of the dynamic
	type of the receiver that declare `foo` have an argument type for it which is a
	subtype of `num`.

	Similarly, the reified type of `new C<int>().bar` will be `void
	Function(Object)`, even though it would have been possible to use the type `void
	Function(List<num>)`.

	Note that the reified type is independent of the static type of the receiver, so
	it does not matter that we consider `new C<int>()` directly, rather than using
	an intermediate variable whose type annotation is some supertype, e.g.,
	`C<num>`.

	In the first example, `foo`, there is a loss of information because we are
	(dynamically) allowed to assign the function to a variable of type `void
	Function(Object)`. Even worse, we may assign it to a variable of type `void
	Function(String)`, because `void Function(Object)` (that is, the actual type
	that the function reports to have) is a subtype of `void Function(String)`. In
	that situation, every statically safe invocation will fail, because there are no
	values of type `String` which will satisfy the dynamic check in the function
	itself, which requires an argument of type `int` (except `null`, of course, but
	this is rarely sufficient to make the function useful).

	In the second example, `bar`, the same phenomenon is extended a little, because
	we may assign the given torn-off function to a variable of type `void
	Function(String)`, in addition to more reasonable ones like `void
	Function(Object) `, `void Function(Iterable<Object>)`, and `void
	Function(Iterable<int>)`.

	It is certainly possible to specify a more "tight" reified type like the ones
	mentioned above. In order to do this, we would need the least upper bound of all
	the statically known types in all supertypes of the dynamic type of the
	receiver. This would involve a least upper bound operation on a set of types,
	and it would involve an instantiate-to-bounds operation on the type parameters.

	The main problem with this approach is that some declarations do not allow for
	computation of a finite type which is the least upper bound of all possible
	instantiations, so we cannot instantiate-to-bound:

	```dart
	// There is no finite type `T` such that all possible values for `X`
	// and no other types are subtypes of `T`.
	class D<X extends D<X>> {}
	```

	Similarly, some finite sets of types do not have a denotable least upper bound:

	```dart
	class I {}
	class J {}

	class A implements I, J {}
	class B implements I, J {}
	```

	In this case both of `A` and `B` have the two immediate superinterfaces `I` and
	`J`, and there is no single type (that we can express in Dart) which is the
	least of all the supertypes of `A` and `B`.

	So in some cases we will have to error out when we compute the reified type of a
	tear-off of a given method, unless we introduce intersection types and infinite
	types, or unless we find some other way around this difficulty.

	On the other hand, it should be noted that the common usage of these torn-off
	functions would be guided by the statically known types, which do have the
	potential to keep them "within a safe domain".

	Here is an example:

	```dart
	main() {
	List<int> xs = <int>[];
	void Function(int) f1 = xs.add; // Same type statically, OK at runtime.
	void Function(num) f2 = xs.add; // Statically a downcast, can warn, OK at runtime.
	void Function(Object) f3 = xs.add; // A downcast, can warn, OK at runtime.
	void Function(String) f4 = xs.add; // An unrelated type, error in strong mode.

	List<num> ys = xs; // "Forget part of the type".
	void Function(int) f5 = ys.add; // Statically an upcast, OK at runtime.
	void Function(num) f6 = ys.add; // Statically same type, OK at runtime.
	void Function(Object) f7 = ys.add; // Statically a downcast, OK at runtime.
	void Function(String) f8 = ys.add; // An unrelated type, error in strong mode.

	List<Object> zs = ys;
	void Function(int) f9 = zs.add; // Statically an upcast, OK at runtime.
	void Function(num) fa = zs.add; // Statically an upcast, OK at runtime.
	void Function(Object) fb = zs.add; // Statically same type, OK at runtime.
	void Function(String) fc = zs.add; // Finally we can go wrong silently!
	}
	```

	In other words, the static typing helps programmers to maintain the same level
	of knowledge (say, "this is a list of `num`") consistently, even though it is
	consistently incomplete ("it's actually a list of `int`"), and this helps a lot
	in avoiding those crazy assignments (to `List<String>`) where almost all method
	invocations will go wrong.


	## Updates

	* Jun 1st 2018, version 0.6: Removed specification of variance, for which
	the normative text is now part of the language specification. Adjusted
	the wording to fit the slightly different definitions of variance given
	there. The meaning of this feature specification has not changed.

	* Feb 1st 2018, version 0.5: Added specification of override checks for
	parameters which are covariant from class.

	* Nov 24th 2017, version 0.4: Modified the definition of what it takes to be
	a covariant parameter: Some cases were previously incorrectly omitted.

	* Nov 11th 2017, no version number specified: Clarified examples.

	* Apr 21st 2017, no version number specified: Some typos corrected.

	* Feb 16th 2017, no version number specified: Initial version.