OLD | NEW |
1 # Informal Specification: Parameters that are Covariant due to Class Type Parame
ters | 1 # Informal Specification: Parameters that are Covariant due to Class Type Parame
ters |
2 | 2 |
3 Owner: eernstg@. | 3 Owner: eernstg@. |
4 | 4 |
5 ## Summary | 5 ## Summary |
6 | 6 |
7 This document is an informal specification which specifies how to determine the | 7 This document is an informal specification which specifies how to determine the |
8 reified type of a tear-off where one or more parameters has a type annotation in | 8 reified type of a tear-off where one or more parameters has a type annotation in |
9 which a formal type parameter of the enclosing class occurs in a covariant | 9 which a formal type parameter of the enclosing class occurs in a covariant |
10 position. This feature has no effect in Dart 1, it only affects strong mode and | 10 position. This feature has no effect in Dart 1, it only affects strong mode and |
(...skipping 258 matching lines...) Expand 10 before | Expand all | Expand 10 after Loading... |
269 The dynamic checks associated with invocation of such a function are still | 269 The dynamic checks associated with invocation of such a function are still |
270 needed, and they are unchanged. | 270 needed, and they are unchanged. |
271 | 271 |
272 _That is, a dynamic error occurs if a method with a covariant parameter p is | 272 _That is, a dynamic error occurs if a method with a covariant parameter p is |
273 invoked, and the actual argument value bound to p has a run-time type which is | 273 invoked, and the actual argument value bound to p has a run-time type which is |
274 not a subtype of the type declared for p._ | 274 not a subtype of the type declared for p._ |
275 | 275 |
276 ## Alternatives | 276 ## Alternatives |
277 | 277 |
278 The "erasure" of the reified parameter type for each covariant parameter to | 278 The "erasure" of the reified parameter type for each covariant parameter to |
279 `Object` may seem agressive. | 279 `Object` may seem aggressive. |
280 | 280 |
281 In particular, it ignores upper bounds on the formal type parameter which gives | 281 In particular, it ignores upper bounds on the formal type parameter which gives |
282 rise to the covariance due to class covariance, and it ignores the structure of | 282 rise to the covariance due to class covariance, and it ignores the structure of |
283 the type where that formal type parameter is used. Here are two examples: | 283 the type where that formal type parameter is used. Here are two examples: |
284 | 284 |
285 ```dart | 285 ```dart |
286 class C<X extends num> { | 286 class C<X extends num> { |
287 void foo(X x) {} | 287 void foo(X x) {} |
288 void bar(List<X> xs) {} | 288 void bar(List<X> xs) {} |
289 } | 289 } |
(...skipping 89 matching lines...) Expand 10 before | Expand all | Expand 10 after Loading... |
379 void Function(Object) fb = zs.add; // Statically a same type, OK at runtime. | 379 void Function(Object) fb = zs.add; // Statically a same type, OK at runtime. |
380 void Function(String) fc = zs.add; // Finally we can go wrong silently! | 380 void Function(String) fc = zs.add; // Finally we can go wrong silently! |
381 } | 381 } |
382 ``` | 382 ``` |
383 | 383 |
384 In other words, the static typing helps programmers to maintain the same level | 384 In other words, the static typing helps programmers to maintain the same level |
385 of knowledge (say, "this is a list of `num`") consistently, even though it is | 385 of knowledge (say, "this is a list of `num`") consistently, even though it is |
386 consistently incomplete ("it's actually a list of `int`"), and this helps a lot | 386 consistently incomplete ("it's actually a list of `int`"), and this helps a lot |
387 in avoiding those crazy assignments (to `List<String>`) where almost all method | 387 in avoiding those crazy assignments (to `List<String>`) where almost all method |
388 invocations will go wrong. | 388 invocations will go wrong. |
OLD | NEW |