How does extension method resolution interact with short circuiting null aware operators?

[leafpetersen]

With non-nullable types, we propose to make the null aware operators short-circuiting. I believe that at least some proposals for the extension method patterns would allow you to write the following extension:

extension NullInt on int? {
  int toDefault() => this == null ? 0 : this;
}

And I believe that the proposals would match this extension to e.toDefault() when e has type int or int?. So the question is, what are the semantics of:

(null as double?)?.toInt().toDefault()

In particular, does this desugar using ordinary method desugaring as:

  let tmp = (null as double?) in (tmp == null) ? null : toDefault(tmp.toInt())

or do we treat extension methods that apply to null differently and desugar as:

  let tmp = (null as double?) in toDefault(tmp == null ? null : tmp.toInt())

cc @munificent

[lrhn]

We should definitely make the null-aware operator short-circuiting.
We should also make extension methods work just like normal methods, to as great an extend as absolutely possible.

That means that

(null as double?)?.toInt().toDefault()

would then rewrite to:

let tmp = null as double? in tmp == null ? null : tmp.toInt().toDefault();

The type of tmp.toInt() is int, so it matches the NullInt extension's type pattern,
and it ends up as:

let tmp = null as double? in tmp == null ? null : NullInt.toDefault(tmp.toInt());

[leafpetersen]

This was also discussed here: #392 .

[leafpetersen]

This is resolved in favor of treating all method invocations (whether instance or extension) uniformly.