Erik Ernst comments

Results 1003 comments of


                                            Erik Ernst

The flatten function depends on static type, so it should be declared for type variables.

True again, we do need to consider type variables with `S?` and `FutureOr` as well. - If `T` is a type variable `X` with bound `B` then `flatten(T) = flatten(B)`....

The flatten function depends on static type, so it should be declared for type variables.

> if the runtime behavior is only to await a `Future`... But `await e` should await _any_ future, and it's up to the static type of the expression to faithfully...

The flatten function depends on static type, so it should be declared for type variables.

> That's what I thought Ah, you're right, we _do_ specify `await e` with a check (that often needs to be a dynamic check) for whether we have a `Future`,...

The flatten function depends on static type, so it should be declared for type variables.

```dart import 'dart:async'; void main() async { final FutureOr fut = Future.value(); var x = await fut; // int i = x; shows that `x` has type `Object`. print(x); //...

The flatten function depends on static type, so it should be declared for type variables.

@lrhn wrote: > For `await e` where `e` has static type `FutureOr`, the specification > says to only await a `Future`, not a `Future` (which is an `Object`). **Thinking again**,...

The flatten function depends on static type, so it should be declared for type variables.

Cf. https://github.com/dart-lang/language/pull/2333.

The flatten function depends on static type, so it should be declared for type variables.

I'm working on an update to the language specification that introduces a number of sections about type inference (to be landed after the null safety updates). I think the need...

Provide explicit access to the default values of parameters

> making default values const values that are named and can be used in any context Yes, I agree that this would be useful, but that is actually what the...

Users want to define union or union-like APIs

#148 introduces 'case functions', which is one way to handle the issues described here. Considering some points raised above: @matanlurey wrote: > It does not allow dynamic calls Case functions...

Users want to define union or union-like APIs

@TzviPM wrote: > The dart type system didn't help me to narrow the type of `node` within the branches of the program [Edit: Checking again, `node` wasn't an instance variable,...