Paul Berry

> cc @stereotype441 Am I correct that this is one of the cases that would be handled if we explicitly track the "nonNull" sets? @leafpetersen Yes, I believe it would,...

> I'm not sure what the general behavior you're proposing is. There are plenty of other cases where a `?.` in a subexpression of an `if` condition does not imply...

> If we track more inferences through null-aware accesses, I guess it would mean: > > For `x?.foo` where `X.foo` is non-nullable: > > * `x?.foo` is `null` implies `x`...

> @stereotype441 How much work is this (either as a general feature, or to hit just the `b ?? false` case)? Given that this hits some common recommended patterns I'd...

@natebosch found another example that I think would be addressed by this fix: ```dart String? current while((current = next()) != null && current.isNotEmpty) { // Error, should be current!.isNotEmpty ```

I've started to work on this using the idea of tracking `null` and `nonNull` models of each expression. as @leafpetersen suggested back in https://github.com/dart-lang/language/issues/1224#issuecomment-693702127. The rules I'm considering would look...

@jodinathan Sorry, no. The feature set for 2.15 has already been decided upon, and it doesn't include a fix for this.

cc @leafpetersen @mit-mit @lrhn @eernstg @munificent @natebosch @jakemac53

I don't know of a place where this particular rule is specified. Generally type inference is not very well specified, and even when it is, a lot of the specs...

I think it would be fairly straightforward. We would have to decide whether it means "at this line" or "at this token position", and how it applies to changes that...