'is' check in a trinary operator should do type promotion

[kevmoo]

...er, whenever it's called.

void foo(Event e) {
  var inputEvent = e is InputEvent ? e : null;

  // Getting error "Type checked failed. e (Event) is not of type InputEvent 
  bar(e);
}

void bar(InputEvent e) { }

[vsmenon]

@kevmoo Can you recheck this? I'm not seeing any problems as of:

> dartanalyzer --version
dartanalyzer version 1.13.0-dev.3.1

[kevmoo]

Here's the concrete error I'm getting

Analyzing [lib/stagexl.dart]...
[error] Type check failed: inputEvent (T) is not of type InputEvent (/Users/kevmoo/source/github/stageXL/lib/src/events/event_stream.dart, line 199, col 28)
[error] Type check failed: MockSound.load(url, soundLoadOptions) (Future<Sound>) is not of type Sound (/Users/kevmoo/source/github/stageXL/lib/src/media/implementation/audio_element_sound.dart, line 37, col 16)
[error] Type check failed: MockSound.load(url, soundLoadOptions) (Future<Sound>) is not of type Sound (/Users/kevmoo/source/github/stageXL/lib/src/media/implementation/web_audio_api_sound.dart, line 34, col 14)

For https://github.com/bp74/StageXL at bp74/StageXL@37a4ec9

dartanalyzer --strong lib/stagexl.dart

> dartanalyzer --version
dartanalyzer version 1.13.0-dev.5.0

[jmesserly]

and here's the code: the is https://github.com/bp74/StageXL/blob/37a4ec987d9b97447c13928240b2d6586e9ac1be/lib/src/events/event_stream.dart#L187
the error on this line: https://github.com/bp74/StageXL/blob/37a4ec987d9b97447c13928240b2d6586e9ac1be/lib/src/events/event_stream.dart#L199

[jmesserly]

@kevmoo type promotion won't happen here, as spec'd in Dart Language.

What is going on: we know T extends Event and event is a T. However, T could be any subtype of event, including a more specific one. We cannot know for sure that InputEvent is the correct promotion.

I'll add this case to #274, but in the short-to-medium term I don't think we can do anything about this case.

In general, type promotion as currently specified is fairly broken, but it's not clear that it can be fixed. I think we need new syntax like Pattern Matching.

[jmesserly]

@vsmenon @leafpetersen unless we can treat the generic parameter T as if it's Event? I seem to recall we had some issues with that, e.g. Point<T extends num> where T was functioning more like dynamic than num.

[jmesserly]

Eh, strike my suggestion above, that would break assigning the "promoted" variable to a variable of type T, which would be bad.

[jmesserly]

folding this into #274

[jmesserly]

(specifically, this is an example of the existing case "if the tested type S is not a subtype of T, the test won't promote. You'd have to track a union type.")