Make the getter of a final instance variable in a constant receiver a constant expression

[eernstg]

This is a proposal to add a new kind of constant expressions:

Assume that e is a potentially constant expression and v is an identifier; in this case e.v is potentially constant. Assume that e is a constant expression that evaluates to an instance of a class C that declares a final instance variable v. In this case e.v is a constant expression.

With this definition, evaluation of e.v is guaranteed to be an invocation of the implicitly induced getter named v. This does not involve execution of user-written code, and it can be done at compile time.

This allows constant expressions to use a small amount of the expressive power which is available to non-constant expressions, but has so far been out of reach for constant expressions. For example:

class Person {
  final String firstName, lastName;
  const Person(this.firstName, this.lastName);
}

class Address {
  final String fullName;
  // ...
  const Address.fromNames(String firstName, String lastName): fullName = '$firstName $lastName ...';
  const Address.fromPerson(Person person): fullname = '${person.firstName} ${person.lastName} ...';
}

void main() {
  const person = Person('John', 'Doe');
  const address1 = Address.fromNames(person.firstName, person.lastName);
  const address2 = Address.fromPerson(person);
}

With the current rules we have to use an approach like in address1, because we can't pass multiple constant objects to the Address constructor using a single object which is then explored.

With this feature, we can use the more encapsulated approach of address2. In this case, person is passed to the Address constructor which will then look up its members as needed in order to arrive at the same result.

Another case which is covered as a subset of this feature is the proposal in #2780, which is about enumerated values.

All in all, it seems both benign and useful to allow constant expressions to support this very fundamental kind of abstraction.

---

Update: Based on @lrhn's comment, I think we should require an explicit marker, such as const, on any getter which is intended to be constant, and on any variable whose implicitly induced getter should be constant. The explicit marker is needed because we would otherwise rely on implementation details of getters in order to accept a given getter as constant, and that would be too easy to break by accident.

Also note the generalization mentioned here which will allow many explicitly written getters to be constant.

As a result of these changes, the following would be supported:

class Person {
  const String _name1, _name2;
  const bool _reversed;
  const Person(String personName, String familyName, {bool reversed = false})
    : _name1 = name1, _name2 = name2, _reversed = reversed;
  const String get firstName => reversed ? _name2 : _name1;
  const String get lastName => reversed ? _name1 : _name2;
  String toString() => "$firstName $lastName";
}

Note that we omit final on variable declarations which are declared to have a constant getter (by having const), because it would be an error for such a variable to be non-final.

[lrhn]

Not without an extra marker, like const String fullName;, so the author can opt in to the getter being accessible as constant.

Being a final instance variable is not part of the interface. It's just a getter, and it can be any getter.

Otherwise someone writing the Person class implicitly allows others to use their firstName getter as constant, which makes it a breaking change to change it to:

class Person {
  final String _name1, _name2;
  final bool _reversed;
  const Person(String personName, String familyName, {bool reversed = false})
    : _name1 = name1, _name2 = name2, _reversed = reversed;
  String get firstName => reversed ? _name2 : _name1;
  String get lastName => reversed ? _name1 : _name2;
  String toString() => "$firstName $lastName";
}

(To support languages where you write the family name first.)

This rewrite should be non-breaking today.
If someone has started using const Person(...).firstName as constant, it will break them.

And the only way to avoid this constant lock-in would be to have private fields with public getters, to not expose the final instance variables publicly, exactly what getter/variable symmetry exists to avoid.

So, no. Not without some opt-in.
Or optionally: Only with the same library that declares the field, and even then, only if it can't possibly be implemented outside of the library. (So final/sealed sub-classes all the way down, which do not have a getter.)

[eernstg]

Being a final instance variable is not part of the interface. It's just a getter, and it can be any getter.

I agree completely that we should limit the amount of implementation details which are leaked by the rules of the language, and revealing that a particular property access will read stored data respectively compute and return a result is an example of such an implementation detail.

However, we don't have to limit the constant getters such that they can only be implicitly induced getters of final instance variables. We could generalize this to allow a substantial set of explicitly written getters:

A getter g is constant if ...

• it is the implicitly induced getter of a final instance variable (whose name must then also be g).
• it has a body of the form => e where e is a this-constant expression.

A this-constant expression is an expression which is constant when this is considered to be a constant expression.

In particular, the following expressions are this-constant:

• a constant expression.
• this.
• this.g, where g is a constant getter.
• e1 + e2, where e1 and e2 are this-constant expressions which are both evaluating to an instance of int or double, or both evaluating to an instance of String, such that + denotes an instance member (not an extension member).
• etc, generalizing all the other possible forms of constant expressions to allow this.

This means that the dividing line is very different from "stored" vs. "computed", which implies that we are not revealing this particular aspect of the implementation.

Considering the example:

class Person {
  final String _name1, _name2;
  final bool _reversed;
  const Person(String personName, String familyName, {bool reversed = false})
    : _name1 = name1, _name2 = name2, _reversed = reversed;
  String get firstName => reversed ? _name2 : _name1;
  String get lastName => reversed ? _name1 : _name2;
  String toString() => "$firstName $lastName";
}

This is fine, it is still the case that firstName is a constant getter, because reversed ? _name2 : _name1 is a this-constant expression (where this occurs three times, implicitly), and similarly for lastName. You can't do everything, but that's a given for constant expressions.

So, no. Not without some opt-in.

It would definitely be worth considering an explicit opt in as well. It would then be possible to declare a final instance variable and a getter as const.

Update: The proposal in the original posting now includes the explicit marker and the generalized constant getters.

[lrhn]

We can definitely define both const fields and const getters, but you still have to opt in. Or have a way to opt out, but that's a migration nightmare, and the default that people just write should not be promising anything.
Like for every other const guarantee that an author can make, they have to make it explicitly.

And if we have const getters, we can also have const functions with potentially constant expressions as bodies, which can be invoked as part of const evaluation. #2222. Heck, we can even add "potentially constant statements", #4261.

Maybe even const operators, but it'll still be hard to make const [1,2,3]'s operator[] be const without a visible subtype that the constant list can have, because otherwise every subclass of List must also implement it as constant.

See also #299.