Erik Ernst

The feature spec proposal at https://github.com/dart-lang/language/pull/1230 does consider the use of the modifier `covariant` on an instance method parameter (see line 312 for an example), and I don't think we...

Cf. discussion IRL with Lasse, it may be too expensive to do what I proposed (even though my proposal makes it OK for `identical(c1.typeArgument, c2.typeArgument)` to return false in [this...

An update on the status of this issue as of August 2022: The null safety feature specification now specifies a [run-time equality](https://github.com/dart-lang/language/blob/master/accepted/2.12/nnbd/feature-specification.md#runtime-type-equality-operator) relation on reified types (implemented by operator `==`)....

> I'd be very wary about requiring canonicalization of run-time allocated values ... Right, this kind of situation is exactly the reason why I said > We might choose to...

This sounds good to me! There could be a soundness problem if `e` allows for new kinds of control flow (like `if ((let x = goto L in 1) is...

Of course, we might as well mention that the test which is the topic of this issue _can_ be expressed today, if we're willing to pay for an allocation of...

Surely, `2.runtimeType` should return the reification of `int`, and that object should have a type that implements `Type` (this essentially means that it would have the type argument `int` _at_...

We wouldn't be able to (soundly) promote `T` based on a type test on the value of `arg`: `T` could perfectly well be `Object` even though `arg` is a `Constraint`,...

With https://github.com/dart-lang/language/issues/2269, we could do this: ```dart Widget makeWidget(bool isFoo) => Bar( a: 1, b: 2, c: isFoo ? 3 : default, ); ``` `default` is the actual syntax that...

@Cat-sushi, do you have an idea how you could then maintain null safety for optional parameters? That is, how would you help developers avoiding to pass null by accident, because...