Value fields

[leafpetersen]

Field reads cannot in general be promoted based on null checks or instance checks because stability of the result cannot be guaranteed. Older overview summary here. Various proposals have been floated to resolve this based on either providing a way for APIs to opt into promotion (e.g. stable getters) or by providing better ways to bind a local variable (search for the label field-promotion for some discussion issues).

This issue sketches out an approach based on adding a new modifier on fields which enforces that the field has value semantics (in the sense that a read of the field is guaranteed to be idempotent). This is enforced by disallowing overriding a value field with a getter.

To enforce this, we add a new member modifier val which can be used to modify a field in place of final.

class A {
   val int x;
   A(this.x);
}

A val field has the same semantics as a final field, with the following modification:

• It is a static error to override or implement a val field with anything other than another val field.
• It is a static error to override or implement a val field with a noSuchMethod forwarder.

As with final fields, a val field may be declared late.

A val field may implement/override a final field or a getter.

A read of a val field is subject to promotion.

cc @dart-lang/language-team

[jakemac53]

Possibly obvious, but I do want to point out that these value fields would also effectively not be mockable. In general they shouldn't be mocked anyways, so that is a bonus in my book. But it could make migrating to a value field harder for certain use cases. Or some people might not use them because of it.

[jakemac53]

Are we sure that val should imply final? I understand that we would still only get promotion for final val fields, but there might be some value in the ability to enforce no overridden setter/getter, for non-final fields.

[leafpetersen]

Possibly obvious, but I do want to point out that these value fields would also effectively not be mockable.

This is also true of stable getters, by the way. But yes, this is a concern. They are actually mockable if you can generate a field in the mock with an initializer or a constructor, but you cannot programmatically set the value. But I think this is an essential component of any proposal in this space. If you can programmatically mock a property you by definition can't soundly promote it.

Are we sure that val should imply final? I understand that we would still only get promotion for final val fields, but there might be some value in the ability to enforce no overridden setter/getter, for non-final fields.

Interesting. My initial take is that I'd hate for people to be writing final val SomeType. final is already kinda verbose. Do we have any examples of good use cases? It feels a bit stretched to me.

[jakemac53]

Do we have any examples of good use cases? It feels a bit stretched to me.

I think for any data class like object it would be a nice property to enforce, as it enforces a simpler mental model. You always know exactly what a call to the getter/setter of the fields are doing, just a simple assignment or read. And not all of these objects are immutable (although that is a common practice).

I do also wonder if it could make the implementations better, although today I assume it's fairly easy to discover fields that never have a custom getter/setter and optimize them. If that does result in any performance or code size benefit, it would give users a way of enforcing that they always get those benefits.

Interesting. My initial take is that I'd hate for people to be writing final val SomeType. final is already kinda verbose. Do we have any examples of good use cases? It feels a bit stretched to me.

Definitely agreed, just val is much nicer than final val.

[leafpetersen]

It's worth mentioning that I don't actually think that overriding is really what users mostly want here. I suspect that a better (but possibly much more complex to design, use, specify and implement) variant of this would be one in which the field is non-virtual (but implementable?), but the initializer is virtual. That is, I suspect that most uses of overriding fields are not because users want to have two different slots in the object, but rather because users want to change the initialization of the field in some way. So perhaps a different take on this would be to forbid overriding of the field, but to provide a way to override the initialization of the field. It's not immediately clear what the right syntax for overriding the initializer is though. What do you do about this parameters? And what about initializer lists? And what do accesses through super do?

[leafpetersen]

think for any data class like object it would be a nice property to enforce, as it enforces a simpler mental model.

This is fair. In terms of syntax, I guess var int x is available. You'd always have to specify the type though.

Maybe go the other way: mutable val to make a mutable semi-virtual field?

[jakemac53]

It's worth mentioning that I don't actually think that overriding is really what users mostly want here.

100%, it is honestly surprising to me that we allow overriding fields at all, it is super weird imo, and most likely it's just a footgun. I can't imagine any circumstance in which I would approve any code that does this. Put it on my list of Dart 4 breaking changes, to disallow it entirely (I assume it is allowed for field vs getter/setter symmetry reasons, but I think that is a mistake, we constantly make compromises to maintain that, and derive little benefit imo).

Honestly, we should probably have a lint for this.

I suspect that a better (but possibly much more complex to design, use, specify and implement) variant of this would be one in which the field is non-virtual (but implementable?), but the initializer is virtual

I don't think it is necessary to support the virtual initializer. If a class wants its subtypes to be able to customize the initial value of a field, it should expose a constructor parameter to do so. If anybody really wants to support this pattern of changing the initial value by overriding the old field with a totally new field, well they can use regular fields and not get promotion. I don't see an issue with that. I highly doubt it is common, and would be pretty horrified to learn otherwise :).

[lrhn]

100%, it is honestly surprising to me that we allow overriding fields at all, it is super weird imo, and most likely it's just a footgun.

It's true that the getter/field symmetry is mainly about different implementations of the same interface using different strategies, or the same class changing strategy over time, not so much that the same class hierarchy overrides a field with a getter. (Although, overriding a getter with a field seems fine.)

It does happen, to add some side effect and then forward to the super setter (usually) or getter. It's not shadowing as much as it's elaborating on top of the existing field. Or adding a throwing setter to hide the mutable field (hopefully rare, it's better to have no setter at all then.)

This comes back to my arguments for wanting getters over fields. It's about modelling state. A getter has no state, a field does. Having two states for the same name is what's weird, even from a state modelling perspective.

So it's not about overriding fields being weird, as much as it's overriding fields with fields. That is weird.
Overriding with a getter or setter that does something more is perfectly reasonable (IMO).

Maybe because I don't assign any external semantic meaning to something being a field. It's an implementation choice for how to implement a getter, and a design choice about the object's internal state. Both are internal choices that do not affect the API.

But that's also what makes it harder to prohibit someone in another library from overriding a field with a field.
They shouldn't know that they are overriding a field. And if they aren't today, it shouldn't become a breaking change for the superclass to change their get-getter to an implicit field getter.
Instead they should worry that they're hiding something that the superclass exposes, making some of its potential internal state unnecessary, however it's implemented. It's a design and modelling issue, not an implementation issue.

(I assume it is allowed for field vs getter/setter symmetry reasons, but I think that is a mistake, we constantly make compromises to maintain that, and derive little benefit imo).

I disagree that we derive little benefit. If we didn't have that, I promise you that every class I wrote would use the private-field/public-getter pattern for every exposed field. And I'd not be alone in that. The Java lesson is real, if we make "fields" special, and limited, then the prudent approach is to never expose one in API you might, ever, hypothetically, want to change to be a getter.
That, or make the class final, which is also prudent.

[jakemac53]

Sorry I wasn't super clear, I specifically meant that overriding fields with fields is the likely footgun. I think that overriding a field with a getter/setter is perfectly fine (and normal), as long as that eventually calls the super getter/setter.

The Java lesson is real, if we make "fields" special, and limited, then the prudent approach is to never expose one in API you might, ever, hypothetically, want to change to be a getter.

If it's only overriding fields with fields that we can agree is "bad" - then you can always change a field to a getter still. But the other way around would potentially be breaking. The "simple" field pattern we have today is not lost though, there is no need to do the private field + public getter.

[eernstg]

I'd love to start using val to express the API level property that a given getter returns the same value if it's invoked multiple times. It's just like starting afresh with the decision to call it final (and then regretting for a decade that it's 5 characters rather than 3), and getting it right this time (with respect to the guarantees actually delivered to clients).

So that's great! ;-)

@jakemac53 wrote:

value fields would also effectively not be mockable

I think it's possible to deal with them in a mocking context: Lots of mock classes contain generated code today, so let's consider a situation where some amount of code generation can be part of the solution.

If you want to mock val T x; such that it has the value v then you can generate code in the mock class such that it has a declaration of the form late val T x = e;, and then you make sure that e evaluates to v at the time where you invoke the corresponding getter x for the first time.

For example, e could be a library variable of type dynamic, and then you could use when and then invocations to assign the desired value to e, and then evaluate that getter.

This means that we can declare a member in the mock which is stable (if we hadn't been able to do that then the mock couldn't even have the desired type). Still, we can determine per-object and rather late which value it should return.

@leafpetersen wrote:

also true of stable getters

The same technique would be applicable with stable getters.

@lrhn wrote:

The Java lesson is real

I'd also assume that the Java community would have stopped saying "don't use public fields, declare a getter and a setter!" many years ago, if it had been such an unnecessary and useless rule.

So I'd very much support the idea that it should be possible to override a val T v; by a getter that returns a stable expression, which could for instance be super.v, but it could also be a constant or any of the other stable expressions.

[lrhn]

About mocking value fields, we can define that the noSuchMethod-forwarder for such a member has the form:

late val type name = this.noSuchMethod(Invocation.getter(#name));

A late val variable should be possible, with and without initializer, the latter meaning it has a setter which can be called once, just like a late final variable. It really is exactly like a final variable with the extra restriction that it cannot be overridden with something non-stable.
A val variable only ever has one value, and if it returns a value, it will return the same value every time in the future, making caching safe. A late val variable may throw until it gets that value.

About Java, Dart has one difference from Java's field/getter-method in that it's possible to change a stable field to a non-stable getter without all uses needing to change. It's only necessary to change the calling code if it relied on stability for promotion, and if it didn't, the syntax keeps working.
Java requires you to change a .foo to .getFoo() to make the migation, which makes the migration much harder.
(C# has managed to put itself in the middle, but because of capitalization tradition, you'd still have to change .field to .Field.)