Surface whether or not a getter can be overridden

[nex3]

In strong mode, a getter may not be overridden if it's defined as a field. For example,

class Super {
  final foo;
  get bar;
}

class Sub extends Super {
  get foo => 12;
  get bar => 13
}

Sub.foo is invalid, whereas Sub.bar is valid. This affects the public API of a class, so it should be mentioned in the documentation. For forwards-compatibility with future explicit member- or class-level control of virtual-ness, it would probably be good to document this as "this getter cannot be overidden in subclasses" or something like that.

cc @munificent @vsmenon

[sigurdm]

We could replace the "getter/setter pair" box with one that says "field"

[srawlins]

I don't understand the premise... any field or setter can be overridden. The code in the summary is not valid (missing abstract, missing ;). I don't think there is anything to do here. It is inconsequential whether a property exists via a field declaration or a getter and/or setter.

[sigurdm]

Hmm - you are right - I vaguely remember discussions around this back when strongmode was a thing.

If you override a field with a getter I believe the storage for the underlying field is still allocated, but the field cannot be reached.

From the spec 10.9.1

Instance variables never override each other. The getters and setters induced by
instance variables do.

Seems like you should not override fields (though you can): https://dart.dev/tools/linter-rules/overridden_fields

In that way it might be valuable to "warn" that something is a field - but I'm not 100% sure

cc @jonasfj as we discussed this earlier today