Make sure type-special-casing for numbers is updated to account for extension types.

[lrhn]

Extension types allow introducing subtypes of num and int.
We should make sure that the special-case rules for typing of int + int are aware of this, and figure out what we want them to do when meeting a surprising subtype of int.

If the rules usees phrasing as "is a non-Never subtype of int", that's no longer guaranteed to be the type int or a type variable with bound or promotion to int, or necessarily use the operator+ of int.

We may just have to add something like "and the + operator an instance member, not an extension type member" to discount a subtype which shadows the instance method with an extension method.

But first we should look at the rules, figure out if there is a problem, and whether or not, if they should be changed.
(We may want extension type subtypes of int to work in some cases, where they wouldn't with the current phrasing. Impossible to know without checking.)

[lrhn]

The current specification is from the null safety change: https://github.com/dart-lang/language/blob/main/accepted/2.12/nnbd/number-operation-typing.md

It does look like it needs to be updated to say that the rules only apply if the subtypes of the number types do not shadow the instance methods using extension type methods.

Will need a terminology for that.

[eernstg]

We have a similar situation when it comes to constant expressions of the form e.length: It is required that

... length denotes an instance getter invocation.

This requirement was added exactly because it should not be possible to make arbitrary computations part of constant expression evaluation, and hence it can't be allowed to be an extension member invocation.

I believe we have very much the same requirements here: The special typing of invocations of operator + and similar members is justified by a non-standard (higher) level of knowledge about the actual behavior of those members, so we can't allow that behavior to be implemented by non-platform code, and we should be able to ensure this by specifying that the invocation must be an instance member invocation.

[lrhn]

That too.

We probably need to distinguish, in several places, whether a member access is an instance member access or an extension member access, and not allow extension member accesses in constant expressions, and account for them in some other cases.
"If length denotes an instance member, and the receiver implements String, then ..., otherwise it's a compile-time error."

And we should probably also state that for/in, await for, yield* and await ignores extension type methods, by casting their operands to Iterable, Stream or Future before operating on them.
(Unlike toString used by string interpolations, those methods may be shadowed by extension members. We should probably also warn if someone tries to do that for a type which ends up being used by one of those language constructs.)

Not even sure what this is specified as doing today:

extension on Object {
  static int ctr = 0;
  int get length => ++ctr;
}

class C {
  final int size;
  final Object value;
  const C(this.value) : size = value.length;
}
const c = C("string");

The value that length is called on is String, but the length being called is not String.length.
(Our implementations handle it, saying Info: Extension operations can't be used in constant expressions.
const C(this.value) : size = value.length;`. The fact that it's an info suggests it's not in the specification.)

[eernstg]

We probably need to distinguish, in several places, whether a member access is an instance member access or an extension member access, and not allow extension member accesses in constant expressions, and account for them in some other cases.

I believe this has already been specified for constant expressions. In general, it says that the operator/method/getter denotes an instance member invocation. If it doesn't, then that is not a constant expression.

Not even sure what this is specified as doing today:

value.length is not a constant expression, because it is known statically that it resolves to the extension method. This implies that every invocation of that constant constructor is a compile-time error.

We could report the compile-time error for the declaration of the constant constructor itself, but we don't report such errors at the constructor declaration, we only report them for each constant invocation.

However, I agree that we'd need to explicitly ignore extension type members when the extension type is a subtype of Stream in an asynchronous for-in statement, or with yield*. I don't think await creates any issues, and the synchronous for-in statement already specifies that the operations are performed according to a type of the form Iterable<T> for some T.

[lrhn]

value.length is not a constant expression, because it is known statically that it resolves to the extension method.

ACK, I can see we already added the "denotes an instance member invocation" clauses to the constant expressions.

We'll need them on the number type special cases too, then.

We don't define await, await for, yield* in terms of interface members invoked, but we do invoke them, so should say something. Even if it's just "by invoking instance members".