OLD | NEW |
---|---|
(Empty) | |
1 # Strong Mode in the Dart Dev Compiler | |
2 | |
3 ## Overview | |
4 | |
5 In the Dart Dev Compiler (DDC), static strong mode checks are augmented stricter runtime behavior. Together, they enforce the soundness of Dart type annotation s. | |
Leaf
2016/01/15 00:01:10
'augmented with'?
vsm
2016/01/15 20:13:39
Done.
| |
6 | |
7 In general, and in contrast to Dart's checked mode, most safety is enforced stat ically, at analysis time. DDC exploits this to generate relatively few runtime checks while still providing stronger guarantees than checked mode. | |
8 | |
9 In particular, DDC adds the following: | |
10 | |
11 - Stricter (but fewer) runtime type checks | |
12 - Reified type narrowing | |
13 | |
14 ## Runtime checks | |
15 | |
16 In practice, strong mode enforces most type annotations at compile time, and, th us, requires less work at runtime to enforce safety. Consider the following Dar t code: | |
17 | |
18 ```dart | |
19 String foo(Map<int, String> map, int x) { | |
20 return map[x.abs()]; | |
21 } | |
22 ``` | |
23 | |
24 Strong mode will enforce that the function `foo` is only invoked in a manner con sistent with its signature. DDC - which assumes strong mode static checking - i nserts no further runtime checks. In contrast, standard Dart checked mode would check the type of the parameters - `map` and `x` - along with the type of the r eturn value at runtime on every invocation of `foo`. Even Dart production mode, depending on the implementation and its ability to optimize, may require simila r checking to dynamically dispatch the map lookup and the method call in the bod y of `foo`. | |
25 | |
26 Nevertheless, there are cases where DDC still requires runtime checks. (Note: D DC may eventually provide a mode to elide these checks, but this would violate s oundness and is beyond the scope of this document.) | |
27 | |
28 ### Implicit casts | |
29 | |
30 Dart has flexible assignability rules. Programmers are not required to explicit ly cast from supertypes to subtypes. For example, the following is valid Dart: | |
31 | |
32 ```dart | |
33 Object o = ...; | |
34 String s = o; // Implicit downcast | |
35 String s2 = s.substring(1); | |
36 ``` | |
37 | |
38 The assignment to `s` is an implicit downcast from `Object` to `String` and trig gers a runtime check in DDC to ensure it is correct. | |
39 | |
40 Note that checked mode would also perform this runtime test. Unlike checked mod e, DDC would not require a check on the assignment to `s2` - this type is establ ished statically. | |
41 | |
42 ### Inferred variables | |
43 | |
44 Dart's inference may narrow the static type of certain variables. If the variab le is mutable, DDC will enforce the narrower type at runtime when necessary. | |
45 | |
46 In the following example, strong mode will infer of the type of the local variab le `y` as an `int`: | |
47 | |
48 ```dart | |
49 int bar(Object x) { | |
50 var y = 0; | |
51 if (x != null) { | |
52 y = x; | |
53 } | |
54 return y.abs(); | |
55 } | |
56 ``` | |
57 | |
58 This allows it to, for example, static verify the call to `y.abs()` and determin e that it returns an `int`. However, the parameter `x` is typed as `Object` and the assignment from `x` to `y` now requires a type check to ensure that `y` is only assigned an `int`. | |
59 | |
60 Note, strong mode and DDC are conservative by enforcing a tighter type than requ ired by standard Dart checked mode. For example, checked mode would accept a no n-`int` `x` with an `abs` method that happened to return an `int`. In strong mo de, a programmer would have to explicitly opt into this behavior by annotating ` y` as an `Object` or `dynamic`. | |
61 | |
62 ### Covariant generics | |
63 | |
64 | |
65 ### Dynamic operations | |
66 | |
67 ## Runtime type Narrowing | |
68 | |
69 ### Allocation inference | |
70 | |
71 ### Generic methods | |
OLD | NEW |