improve type promotion

[jmesserly]

There are some cases where type promotion won't work. Found while investigating the state of #31.

NOTE: My current thought here is that we should file a DEP for pattern matching, rather than try and hack type promotion into something sensible. The feature as is seems to cause a lot of user confusion.

It roughly falls into a few buckets:

• if the original type of T of v was dynamic, the test v is SomeType won't promote. This leads to some suboptimal codegen in SDK (see strong mode should allow type promotion from dynamic dart-lang/sdk#25486)
• if the tested type S is not a subtype of T, the test won't promote. You'd have to track a union type.
• the type promotion is only valid in the body/else clause of that if statement. There's no analysis of the rest of the method, meaning patterns like if (v is! S) return; don't affect the type of v in the rest of the method body.
• from Sky, we've heard they would like to do assert(v is S); and have v be treated as S for the rest of the method. Sort of like an unchecked (in production mode) cast, similar to S v2 = v but not requiring a second variable name to be introduced.
• from package:yaml, assignment to the variable in a closure will disable all promotion, this is true even if that closure hasn't been defined yet (and therefore, cannot possibly mutate the variable).
• Constrained generic parameter like T extends Event, not promoting to a subtype of Event like InputEvent, see 'is' check in a trinary operator should do type promotion #327

[jmesserly]

one idea here: if we fixed #239, we could have the "strong mode option" let analyzer put their already-better propagated type into the static type instead. That would improve at least some of the cases above.

[bwilkerson]

Analyzer's propagated type isn't always better, but in those few places where it is (such as where we do some flow analysis) you could certainly make use of that information.

[jmesserly]

Maybe the answer here is to do a "pattern matching" DEP rather than try and fix the many issues with type promotion... what concerns me about trying to fix it is we'd need to introduce several kinds of analysis (union types, tracking variable types across the control flow graph) to make the feature reliable. =\

[jmesserly]

(and ultimately, pattern matching is a better solution to the problem)

[jmesserly]

Moved to dart-lang/sdk#25565