Paul Berry

Note: https://github.com/dart-lang/sdk/issues/45663 has a similar stack trace and might be the same issue.

@insinfo were you able to make progress on the migration by supplying the `--ignore-exceptions` flag when running the migration tool?

> I'm 100% OK with that if the rest of the language team is. In our last language team meeting I felt like I was the last holdout who wasn't...

> We could instead though remove the check for `Future`, to make it more consistent with normal `await` : that is, `await p` matches `v` if `v` is a Future...

@leafpetersen: In the issue description you gave this example: ```dart // mixin0.dart import "mixin1.dart"; class A { final int _privateField = 3; void testThisCall() => print(_privateField); } class B {...

For level 0, I think we need to add an exception for extension declarations: they can't safely promote private instance fields on `this`, because inside an extension declaration, `this` is...

We discussed this at length in the language team meeting today, and decided to shift our approach a bit. Rather than ensuring soundness of promotion in library A by restricting...

> > To make this sound, we only need to make one breaking change to the language: Don't delegate private names to `noSuchMethod`. > > I'm not sure if we...

> > * We wouldn't be doing the "level 1" part of Leaf's proposal ("Allow property accesses to final fields (private or not) on private non-escaping classes to promote"). I...

> About this design point: > > > To make this sound, we only need to make one breaking change to the > > language: Don't delegate private names to...