Representation variable of an extension type is not promoted

[sgrekhov]

[Edit eernstg: See https://github.com/dart-lang/language/issues/3342 as well.]

According to the extension type specification representation variable is subject to promotion. But in the current implementation nor analyzer nor CFE don't promote it. For example, they both report errors below

// SharedOptions=--enable-experiment=inline-class

extension type ET1(int? id) {
  void test() {
    if (id != null) {
      id.isOdd; // Error
    }
  }
}

extension type ET2<T>(T id) {
  void test() {
    if (id is int) {
      id.isOdd; // Error
    }
  }
}

main() {
  ET1 et1 = ET1(1);
  if (et1.id != null) {
    et1.id.isEven; // Error
  }

  ET2<num?> et2 = ET2(2);
  if (et2.id != null) {
    et2.id.isEven;  // Error
  }
}

A separate issue for private fields promotion #53439

Tested on the edge SDK (Sept 6, 2023) on Linux x64

[mit-mit]

@eernstg can you comment ?

[lrhn]

The specification does say that.
It doesn't say precisely which kind of promotion is allowed.

I'll assume that it is only something like this-promotion, allowed inside methods of the same declaration.

But we don't have this-promotion, not even in extension members, so I'm not convinced we should have representation object variable promotion at all. It feels like a weird exception to treat that as a promotable local variable, when we don't even for this.

For field-promotion (mk. 2), a representation object accessor is definitely stable, so it can safely be promoted and used as a receiver for field promotion, but only inside the declaring library.

[eernstg]

The specification doesn't spell out the details, but it has been part of the proposal for a long time that the representation variable can be promoted because it's stable (it cannot be overridden, and it is final).

So the intention is that it should be promotable. However, it hasn't been spelled out in detail.

Final private instance variables are currently (3.2) only promotable when they are accessed via this or via a promotable local variable, and (because they are private) only in the same library.

So let's start with that: Promotion only occurs for a representation variable it in the same library as the one that declares the extension type, and only when it is accessed using this.it, or using e.it where e is a stable expression. A stable local variable is a local variable which is final, or which is stable (not mutated) according to the flow analysis. A stable expression is a stable local variable, or it is of the form e.it where e is a stable expression and it is a representation variable, or of the form e._x where _x is a promotable private final class instance variable.

[srawlins]

@johnniwinther @scheglov would it be easiest if I split this into an issue per front-end?

[scheglov]

Probably not. I suspect that promotion will be implemented in shared code.
If we will do it at all.
I see that there are discussions about stable getters in the language repository, don't know if there is something planned.

[srawlins]

I think when @eernstg writes above:

So let's start with that: Promotion only occurs for a representation variable ...

I think he means that this is to be taken as part of the spec today, not a future plan as part of a separate language feature.

[scheglov]

We don't have such word as "stable" in the specification yet.

But it seems reasonable to me that we say that it is promotable because it cannot it overridden, and it is final.
So, maybe this is just a tiny extension on top of the existing promotion for private final fields?

What I don't understand, is the limitation "in the same library as the one that declares the extension type".
Could you explain?

[lrhn]

Currently field promotion only applies to field declared inside the same library, for a number of reason. The main reason is that it makes a final field behave differently from a getter, and outside of the library, there should be no distinction. Whether a getter is written as a get declaration or is the implicit instance variable getter is not part of the interface, and should be able to vary over time without it breaking anyone.
Inside the same library, we consider it OK to depend on the implementation details, since it's your own details, and if you break anything, you'll notice immediately and be able to fix it.

I want "extension type representation variable promotion" to also only apply inside the library where the extension type is declared. Whether an extension type getter is declared as by a get declaration or by being the extension type representation variable is an implementation detail, which can change over time. Nobody else should be able to depend on one particular getter being special.

So if (ext.foo != null) ext.foo.someMethod(), where ext has an extension type and foo is its representation variable, should only promote ext.foo if done inside the same libray which declared the extension type of ext.

[scheglov]

OK, now I understand, thank you.

It is easy to restrict to a single library.
Although I don't quite agree with this motivation.

We develop in Dart on the level of packages, not libraries. I know that the language does not tell anything about packages, but they are the fact of life. It seems natural to declare some extension types in one library, to be used in another library.

[lrhn]

This particular promotion could probably be allowed for an entire package.
We'd have to specify what "package" means to the language, which currently doesn't have any such notion, but it should be possible.

The other field promotions depend on knowing something about the entire program, which is different from knowing the entire package, since the package can contain more files than what are actually in the program. Or each program, when every test is its own program.
Also, it's based on library private names.

[eernstg]

Sorry, this kind of promotion isn't sound after all:

extension type E(num n) {
  void foo() {
    if (n is int) {
      e = E(1.5);
      n.isEven;
    }
  }
}

E e = E(1);

void main() {
  e.foo();
}

The point is that assignment to a variable whose type is an extension type amounts to the same thing as assignment to the representation variable.

So the representation variable may be considered to be final according to all usages inside the extension type (in particular, n = 1.5 is a compile-time error in the example above), but for purposes like promotion it must be considered to be as mutable as the storage location of the "enclosing extension typed object".