Type promotion for `this`

[eernstg]

The reserved word this, when defined, denotes the current instance of the enclosing class, and hence it is known that if this is T yields true then it is sound to promote the static type of this as if this had been a local variable, and similarly for all other situations where the local variable would be promoted.

The promotion of this implies that this gets a different static type (when it is written explicitly, and when it is an implicit part of an instance member access).

class A {
  int a;
  void m() {
    if (this is B) {
      B bb = this; // OK because `this` has type `B`.
      a = b; // OK because it means `this.a = this.b;`.
    }
  }
}

class B extends A {
  int b;
}

However, it is also possible to learn more about type arguments:

class A<X> {
  X x;
  A(this.x);
  void m() {
    if (this is A<int>) {
      x.isEven;
      Iterable<num> xs = [x];
    }
  }
}

class Pair<X, Y> {
  X x; Y y;
  Pair(this.x, this.y);
  void m() {
    if (this is Pair<Y, X>) {
      var tmp = x;
      x = y;
      y = tmp;
    }
  }
}

For simplicity, we could make the choice to support promotion of this with no changes to the treatment of the type parameters of the enclosing class, or with support as an option that we may pursue in the future.

Presumably, it is a nearly non-breaking change to add support for promotion of type parameters, because this only adds more information about said type parameters, it doesn't invalidate existing information. (The change is not completely non-breaking because any change of a static type may give rise to inference of type arguments with different values, and they are reified so the change is observable.)

[mateusfccp]

Please, I struggle with this every time I have to implement a sum type.

[eernstg]

@mateusfccp, is it correct to assume that you need this to have the promoted type, but you do not need the derived promotions of type parameters?

[mateusfccp]

Sorry, @eernstg, I couldn't exactly understand what you meant.

Usually when I make a sumtype I have to make a fold function, where I have to check for each subtype. However, I have to use a placeholder for this, as this won't be promoted.

T fold<T>(...) {
  final _this = this;
  if (_this is A) {
     // ... do something with promoted _this
  } else if (_this is B) {
     // ... do something with promoted _this
  }
}

Alternatively, I use this in the comparisons and cast inside the block, similar to what you did in the first example.

[eernstg]

@mateusfccp, the simplest approach to promotion of this would give you exactly the type for this that you currently get with _this, with no connection to type parameters.

[munificent]

I absolutely love this:

class A {
  void m() {
    if (this is B) {
      B b = this; // OK because `this` has type `B`.
    }
  }
}

class B {}

But I think this is very much a bridge too far:

class A {
  void m() {
    if (this is B) {
      b = 1; // "b" is now in scope because of the promoted implicit `this`.
    }
  }
}

class B extends A {
  int b;
}

I don't think type promotion should interact with the scoping of bare identifiers like this. Say you have a program like:

var name = "top level";

class A {
  m() {
    print(name);
  }
}

class B extends A {
  var name = "in B";
}

main() {
  A().m();
}

This prints "top level". If we used the promoted this for resolving bare identifiers and you change the m() to:

  m() {
    if (this is B) print(name);
  }

Now name resolves to this.name and it prints "in B". That feels pretty surprising to me.

In other words, I think it makes sense to promote the identifier this as if it were a local variable, but not the entire notion of the "current receiver".

[eernstg]

@munificent wrote:

... a bridge too far ...

to let a plain identifier id resolve as this.id where id is only present in the interface of this because of the promotion, and continued

This prints "top level". If we used the promoted this for resolving bare identifiers and you change the m() to:

m() {
  if (this is B) print(name);
}

We actually wouldn't ever re-interpret an identifier like name in this manner: The lexical scope always wins, and the ability to consider id as an abbreviated notation for this.id only kicks in when there is no declaration named id in scope at all.

So we maintain the sanity property that we have today: this will never capture a name which is visible in an enclosing scope.

But it would of course still be possible to use an explicit this, and I suppose that's less controversial:

m() {
  if (this is B) print(this.name); // Prints "in B".
}