Add support for explicit backing fields

[lunakoly]

Please, see explicit-backing-fields.md for the full text in PR #289.

Summary

Sometimes, Kotlin programmers need to declare two properties which are conceptually the same, but one is part of a public API and another is an implementation detail. This is known as backing properties:

class C {
    private val _elementList = mutableListOf<Element>()

    val elementList: List<Element>
        get() = _elementList
}

With the proposed syntax in mind, the above code snippet could be rewritten as follows:

class C {
    val elementList: List<Element>
        field = mutableListOf()
}

[BreimerR]

Interesting read.
Question:
What if the backing field is a var and the actual field is a val.

private class SynchronizedLazyImpl<out T>(initializer: () -> T, lock: Any? = null) : Lazy<T>, Serializable {
    private var initializer: (() -> T)? = initializer
    @Volatile private var _value: Any? = UNINITIALIZED_VALUE
    // final field is required to enable safe publication of constructed instance
    private val lock = lock ?: this

    override val value: T
    /// Other code is here Referenced from kotlin.SynchronizedLazyImpl
}

How would this be catered for?

[LouisCAD]

I have one concern:
It looks like it'll not be possible to use asStateFlow(), and other read-only type conversion methods, unless you want to pay the price of that operation (and memory allocation) being run on each access.

Has the possibility of allowing it been considered, despite the fact that it'd require more than one actual backing field?

[lunakoly]

@BreimerR,

As of now, we assume val properties have immutable backing fields, and var properties have mutable ones.

Thanks for your example, I've added it to the enhancements section.

[lunakoly]

@LouisCAD,

If you call asStateFlow() inside a getter, this call will happen upon each access, true. If you do something like this:

val flow: StateFlow<T>
	field = createSomeMutableStateFlow()
	get() = field.asStateFlow()

Then the smart type narrowing won't work, since it only knows how to deal with the default getters.

[gildor]

It looks like it'll not be possible to use asStateFlow(), and other read-only type conversion methods, unless you want to pay the price of that operation (and memory allocation) being run on each access.

I think it's not a big deal in terms of price, it's just a small object without any actual state, only with 1 reference

[LouisCAD]

How doable would it be to address this use case in the design of this feature, or at least, make some room for it for future evolution?

[pdvrieze]

@BreimerR,

As of now, we assume val properties have immutable backing fields, and var properties have mutable ones.

Thanks for your example, I've added it to the enhancements section.

At least on the jvm that is not valid. "final" and "immutable" are different concepts although they are mostly equivalent. More important is that from a consumer perspective (rather than class implementor/compiler) the assumption cannot be made as the backing field (or lack thereof) cannot be assumed - changing it is API and ABI compatible.

[mcpiroman]

I'm much more after the original proposal, because (from my understanding):

• From a private (/more restricted, like internal) scope a property is essentially accessed directly through a field. This breaks the current encapsulation of backing fields being local to properties and disables the use of custom getter from the private scope.
• In future, the custom getter could be analyzed to work with the Smart Type Narrowing (STN), but it would still need to return the same instance, which would not work for the case like the one mentioned above:

val flow: StateFlow<T>
   field = createSomeMutableStateFlow()
   get() = field.asStateFlow()

• This proposal does not work with delegates, the original does.
• The original would also work very well with setter overloading as mentioned here

You write there are complications with the original proposal - well, my answer to both linked questions are yes and yes, but this could be considered incrementally, just as here you start only with private and internal fields.
You also mention there were problems with overloading, but here in rules you say that the "property must be final", so it's essentially the same in both cases?

So I'd like to iterate on why the former proposal cannot be implemented, I don't see the why now.

[lunakoly]

@LouisCAD,

How doable would it be to address this use case in the design of this feature, or at least, make some room for it for future evolution?

Hypothetically, it's possible to introduce a syntax like flow#field if we really need the direct access. Wouldn't it solve the problem?

[lunakoly]

@pdvrieze,

At least on the jvm that is not valid. "final" and "immutable" are different concepts although they are mostly equivalent. More important is that from a consumer perspective (rather than class implementor/compiler) the assumption cannot be made as the backing field (or lack thereof) cannot be assumed - changing it is API and ABI compatible.

Thanks for your correction. I simply meant that assignment to field is forbidden inside a val property getter:

val test: Int = 1
    get() {
        field = 2
        return field
    }

And right now it works the same for properties with an explicit backing field as well

[lunakoly]

@pdvrieze,

It seems to me, sometimes consumers need more control over the stored value, which brings in backing properties. Feels like introducing a field declaration which guarantees the presence of a backing field is what we need here, isn't it?

[lunakoly]

@mcpiroman,

This breaks the current encapsulation of backing fields being local to properties and disables the use of custom getter from the private scope.

I suppose, analyzing getter return value could still make them usable without loosing the STN.

It's true that the STN may not be able to solve all the problems, but it still solves the base problem that gave birth to this discussion.

Please, keep in mind that "Delegated property cannot have accessors with non-default implementations". The original proposal doesn't mention anything about delegated properties.

From what I see, there's nothing preventing the support for setters overloading in the current proposal. I think it's a bit different topic, not "a direct enhancement".

[lunakoly]

@mcpiroman,

The biggest reason why personally I prefer the new approach is the fact that it's really easy to understand. It builds around the already known idea - a backing field - which is just an implementation detail, and this information may be further used on the implementation side to narrow down the type.

The original proposal doesn't mention how exactly the new getters (the ones with a more permissive visibility) would work. Would they work via the same mechanism as the STN? Then the explicit backing fields syntax seems less cryptic to me. Would they not get called when accessing from the scope relevant to the visibility of the property itself so that we have direct access to the backing field? Then we break the rule "getters are always called". How would they interact with usual getters? Prioritization rules of mixed getters seem unintuitive.

The concept of new "exposing" getters introduces such questions as "can we both override the property and its exposing getter" (while implementing the original proposal, the ability to perform such overrides was added). The use with delegates was also unclear.

[mcpiroman]

@lunakoly

It's true that the STN may not be able to solve all the problems, but it still solves the base problem that gave birth to this discussion.

Mostly yes, but it's better to solve more in one step than less, if only because it should end up being less complicated.

The original proposal doesn't mention anything about delegated properties.

Yes, it also doesn't mention their not supported :). And, it looks to me like they should easily be possible. Right now you can do:

private val _foo by lazy { mutableListOf("cOmPLeX") }
val foo: List<String> get() = _foo

So it could become:

val foo by lazy { mutableListOf("cOmPLeX") }
   public get(): List<String>

Which would not be possible with explicit fields.

From what I see, there's nothing preventing the support for setters overloading in the current proposal. I think it's a bit different topic, not "a direct enhancement".

Yes, I mean that it would be nicely symmetric to have multiple getters and multiple setters.

The biggest reason why personally I prefer the new approach is the fact that it's really easy to understand

So for me at least, this is the other way around. I knew at a glimpse what the original syntax was about (maybe because I already knew of the proposal), and I actually pondered quite a bit on what's going on with the new one:

• Why do I have to mess with a backing field to change the (private) type of a property - two different concepts? What if there's no backing field (actually wait, what if there's no backing field? no delegates, ok, but an accessor?),
• Does accessing the property from private scope now go though the getter or directly though the field? After all the filed has the private type, not accessor.
• Default private for field? Public was always the default.

[The rest of your comment]

So to clarify: my view is that there is ever only one actual getter with body, the other ones are just declarations that say more about it's type (and therefore probably should not have parentheses as proposed), the same way as private get does. I also assume the more private type has to be more narrow. With that I frankly can't imagine any of your concerns.

However, I do see an unmentioned one:

val foo: List<String>
   private get: MutableList<String> // <- Property is visible outside under type List<MutableList>

val bar: List<String>
   private get  // <- Property is not visible outside

These too very closely looking syntaxes have quite a different meaning and so are not intuitive. This is not much of a problem right now because Getter visibility must be the same as property visibility so there is no point in using the latter construct, but may be once this restriction is dropped - most probably to support more visible setters as proposed somewhere.

It's not to say it is perfect either, you may e.g. want to change the order of visibility modifiers so it becomes:

private val foo: MutableList<String>
   public get: List<String>

Which would read as "There is a private property foo of type MutableList<String>, which is also exposed publicly under the type List<String>".