Immutable instance variables should be type promoted.

[Cat-sushi]

Currently instance variables cant't be type promoted, because method/ function call might modify them between type checking and reference.
To put it the other way, immutable instance variable such as final fields, getters without respective setters.
Especially for non-null promotion of NNBD, I think immutable variable should be type promoted.

If there is no function call between type checking and a reference, the instance variable also should be type promoted.

#757 might widen the target of type promotion, even more.

note: this issue is derived from dart-lang/sdk#40077

[lrhn]

Sadly, even that is not sound.

Since Dart does not have final declarations or sealed classes, it is possible for a subclass to override the field getter with a new getter which returns different values each time. The compiler cannot know that this hasn't happened when compiling the original method. (Not without a whole-program analysis to check that the getter is not overridden anywhere, and that's a little too fragile in practice. Adding a getter in one place can cause a method in a superclass to no longer be valid. That's the wrong direction for that kind of dependencies, and that's a bit too fragile).

So, instance getters are definitely out. There doesn't have to be code between the check and the use because the use itself can be code.
(Now, if we had self accesses, we might be able to do something. Say self.foo works like this.foo except that it isn't virtual. It always fetches the foo of the current class, like super.foo fetches it from the superclass. Then we can be sure that self.foo is not overridden. It sadly has the same problem as other static accesses, so ...)

Promoting a static final field could work. The biggest issue with that is that it breaks the getter/field symmetry. If you depend on promotion of a static final field somewhere, and the author decides to change it to a getter instead (say, to log accesses or something), then your code starts failing because it can no longer promote the value. Again, that's fragile because of hidden implementation dependencies, and it makes something that should be a non-breaking change into a breaking change.

[Cat-sushi]

Thank you for your explanation.

[Cat-sushi]

another discussion
#1188