Lasse R.H. Nielsen

> This information could be used in the analyzer to allow dot shorthands when such a type is available Not really. The analyzer cannot allow something that the _language_ disallows....

One thing to worry about is mixin application class canonicalization. I believe some backends conflate mixin application classes from different locations, if they are the same mixin on the same...

I have proposed, and stand by, that we should completely ignore anonymous mixin application classes in **LUB**, including not counting them for _depth_. (I did mean "LUB", fixed.)

That unsoundness of super-member-invocations is not new, and we already deal with it. The `M2.test`'s `super.foo` is valid, type-checked against the `on` type's member signature, but the mixin application `D...

I'm not sure why ignoring the anonymous mixin application class in the depth calculation would be more error prone than anything else. I think it's more confusing, and potentially assumption...

> However, I'd consider the approach where anonymous mixin applications are fully included as "cleaner" than both of those. - It is. It's just not particularly useful. If a user...

TL;DR: You can't promote a top-level variable at all. A `case Something(...)` does promote if the matched expression can be promoted. > the analyzer can't naturally introduce a local `_corePlatform`...

You shouldn't iterate an Iterable more than once. It's possible that a pattern match can satisfy that by keeping an iterator and all previously seen values in its internal state,...

Dart iterables are not a good match for lazy linked lists. They have a length. A better match would be `Iterator`, but it's not a type you often use directly....

That *looks* like it would work, but it's unlikely to be efficient. And I'm not sure `skip(1)` is the implementation you want. It doesn't distinguish between moving past the end,...