lateinit val

[InversionSpaces]

Discussion for the lateinit val proposal. The full text is available here.

Note: This proposal supersedes KEEP-0452 and its discussion, capturing the resulting design decisions.

We propose to support assign-once properties in Kotlin by introducing the AssignOnce property delegate and lateinit val declarations.
Both enforce assign-once semantics at runtime: once initialized, a property throws on reassignment.

AssignOnce is a delegate interface in the standard library:

• Properties delegated to it are not considered stable and thus do not support smartcasts.
• Thread-safe and non-thread-safe implementations are provided out of the box.
• Custom implementations are possible with @SubclassOptInRequired opt-in.

lateinit val is a declaration that bridges the gap between lateinit var and val:

• Supports smartcasts, since the compiler treats the property as stable.
• Compiles to delegation against a thread-safe AssignOnce implementation.

class Example {
    lateinit val service: Service
    var config: Config by assignOnce()

    fun setup() {
        service = createService()
        config = loadConfig()

        // Reassignment throws for both:
        // service = otherService // throws
        // config = otherConfig // throws
    }

    fun use() {
        if (service is SpecificService) {
            service.specificMethod()  // smartcast works
        }
        if (config is SpecificConfig) {
            // config.getSpecificValue() - no smartcast
        }
    }
}

[kyay10]

It is marked with @SubclassOptInRequired, signaling that extending it requires care to preserve the stability contract.
Properties explicitly delegated to AssignOnce are normal delegated properties and do not support smartcasts.

I don't understand the point of this. What's the use of the stability contract if it doesn't end up affecting smartcasts? The only situation I can see is someone explicitly using AssignOnce as a value passed around, and thus they might use it in a way that expects such stability, but I really don't see the point of that.

I see no value in subclassing AssignOnce under the current proposal. It'll offer nothing other than conforming to a rarely-used type. I don't see why I'd ever do that, especially with the opt-in. If it offered smart casts, then I definitely would

[InversionSpaces]

What's the use of the stability contract if it doesn't end up affecting smartcasts?

I want to emphasize that from any point of view AssignOnce won't be "the interface for stable delegates" or "the interface you extend to enable smartcasts". AssignOnce is the interface for delegates implementing assign-once properties, so stability (conventional) contract is corollary of the very concept of assign-once property. It is not like we can drop it because (now) it has no use, so the question is little odd for me personally.

You are right that current proposal provides no specific value from extending AssignOnce. The only benefit is the same as with any other interface: you can abstract code that works with AssignOnce values. I agree that this is a niche use-case, but situation is similar with Lazy right now, and it is used sometimes in user code. I personally would argue that AssignOnce is considerably more meaningful abstraction than Lazy.

If later a proposal introducing general stability for property delegates would appear, it is likely that delegates opted-in extending AssignOnce would be supported.

In general, we see current proposal as reasonably permissive. We expect lateinit val to be the most valuable addition to the language, but we do not restrict users accessing AssignOnce.

[hfhbd]

I like the proposal, but as user, the difference between lateinit var vs lateinit val regarding the annotations and kotlinx-serialization implementation is confusing. From user perspective I would expect they behave the same, except I can't assign a value to a lateinit val twice.

When I migrate my lateinit vars to lateinit vals, I need to:

1. change the target of the annotation during compile time (but https://youtrack.jetbrains.com/issue/KT-19289/Hibernate-Validator-annotations-dropped will solve it)
2. validate the kotlinx-serialization runtime behavior

Especially for kotlinx-serialization, I do see a use-case for lateinit val:

readOnly values used in JSON like database ids.

As I user, I would expect the id field will be set by hibernate/kotlinx-serialization:

{"id": 42, "role": "user"}

@Entity
data class User(
  @Column
  var name : String = ""
) {
  @Id
  @GeneratedValue
  lateinit val id : Long
}

val newUser = User().apply { name = "John") }
save(newUser)
val id = newUser.id // 42

val dtoUser = User("John")
val receivedUser =  sendToServer(Json.encodeAsString(dtoUser)) // {"role": "user"}
receivedUser == "{"id": 42, "role": "user"}"

[InversionSpaces]

Could you please elaborate on why do you think KT-19289 would resolve the issue here? AFAIU, change in annotation defaulting rule (linked to the issue) affects only @property:, which is non-applicable with Java annotations, as well as @field: and @param: which are non-applicable for delegated properties, including lateinit val. So to me solving KT-19289 would not change anything for lateinit vals.

As to your code snippet, I believe you have to specify use-sites explicitly:

@get:Id
@get:GeneratedValue
lateinit val id : Long

Also, does not Hibernate require that it can read id before assigning it to determine if it is a new object (id is null) or already persisted one? This would fail with a lateinit val. Sorry, I am no Hibernate expert.

[IRus]

I strongly vote to make lateinit val as close as possible in semantics/compilation scheme to lateinit var. I.e., regular field, with type, null not allowed, no built-in thread-safety, no extra field overhead, etc.

It still will be useful for many cases where lateinit var used today:

• dependency injection
• regular assignment, like class property + @Before

Main argument here, as @hfhbd mentioned: it would be consistent.
If something requires additional annotation today, it would be the same annotation.

[CLOVIS-AI]

I agree. lateinit val should be consistent with lateinit var, anything else is a footgun.

However I think it should still be thread-safe, because val guarantees safe publication, so lateinit val should too (and var doesn't, so it's consistent that lateinit var doesn't).

If we also add a delegate alternative, that one can have more options/a different default (because it's easier to document the options of a delegate than a language feature itself).

[eupp]

However I think it should still be thread-safe, because val guarantees safe publication

There is a small caveat to this assumption: safe publication for val-s is only guaranteed on JVM (because the JVM itself provides this guarantee for final fields). Kotlin compiler itself does not do anything to enforce it (on other platforms).

[hfhbd]

What's the visibility of the "setter"? Will the assignment only be private?

@Serializable
public data class User(
  val name : String
) {
  public lateinit val databaseId : Long
}

val user = User("John")
val id = user.id // will throw

user.id = 42 // accessible or not?

[InversionSpaces]

No, the setter would be public. You can limit it with private set as with other properties.

[eupp]

Wouldn't it be possible to compile lateinit val without the delegate? Couldn't you compile it as a field with custom getter and setter using AtomicFiledUpdater API on JVM (or VarHandle on Java 9+)?

Basically, the compilation scheme for class Example<T> { lateinit val property: T } would look like this:

class Example {
    @Volatile
    private var _property: Any? = UNINITIALIZED

    fun getProperty(): T {
        val p = _property
        if (p === UNINITIALIZED) throw TODO()
        return (p as T)
    }

    fun setProperty(v: T) {
        val updated = propUpdater.compareAndSet(this, UNINITIALIZED, v)
        if (!updated) throw TODO()
    }

    private companion object {
        private val propUpdater = AtomicReferenceFieldUpdater.newUpdater(
            Example::class.java, Any::class.java, "_property"
        )
    }
}

And on Native. instead of AFU/VarHandle APIs, I believe it is possible to use the same intrinsics that Atomics are using internally.

So given KEEP's arguments for delegate:

1. It provides thread-safety through the delegate implementation without requiring additional fields to store synchronization primitives.

It supports both nullable types and dependency injection at the same time:
2. A sentinel object is used to represent the uninitialized state instead of null.
3. Dependency injection frameworks can target the property setter, resolving the right type through reflection.

4. It prevents Java code from modifying the stored value directly, as the underlying field is not exposed.

with the field-based compilation scheme:

1. thread-safety is still achieved via AFU/intrinsics;
2. sentinel object is used in the same vein as in delegate, so nullable types are still supported;
3. not sure about dependency injection, but I guess DI can still target the setter?
4. the underlying field is private, so still not exposed outside of the class itself.

[InversionSpaces]

Yes, DI can target the setter in this case.

Overall, if we hide the backing field completely (in particular, make @field: annotation use-site target inapplicable, although a backing field exists), this implementation seems to provide exactly the same feature surface for lateinit val as delegation does.

Note: The AtomicReferenceFieldUpdater can be made a static class field on JVM, so companion object is not necessary.

[InversionSpaces]

After internal discussions, taking into account your feedback, we decided to:

• Adopt compilation scheme for lateinit val proposed by @eupp in this comment
• Refrain from introducing AssignOnce delegate and delegate-based approach to declaring assign-once properties at this point

The KEEP is updated accordingly. We welcome your feedback.

[hfhbd]

With the new hidden backing field, will the implementation in the Kotlin compiler also include kotlin-serialization plugin support?

Of course other serialization frameworks will need to update their code, but I would expect, the built-in Kotlin serialization plugin will support (de-) serialization like a nullable optional field, similar to lateinit var.

Because the serialization plugin is part of the Kotlin compiler/release cycle, could you clarify the design in the proposal?

[InversionSpaces]

Support from kotlinx.serialization will be there as soon as the team has capacity to implement it.
Quite possibly, lateinit vals would not be supported while they are experimental.

Yes, (de-)serializing to a nullable optional field seems to be the only reasonable option.
But I believe it is better to leave the exact design to the team in charge.

[lppedd]

So DI annotations must use an explicit @set: use-site target to reach the generated setter

This looks very weird and definitely it isn't good UX from a DI user perspective. You'll get a lot of "???" moments here.
Can this somehow be avoided so that lateinit var to lateinit val is a single character transition?

Note that DI users now must use lateinit var, but as soon as lateinit val will be available, everyone will use the val alternative.

[InversionSpaces]

Can this somehow be avoided

Unfortunately, we don't see a way to do it now without compromising safety. Introducing lateinit val with this limitation makes it easy to relax restrictions in the future if they prove to be a major pain-point. Going other way around would be harder.

Personally, I don't see why making it one-symbol-change is such a big concern: the IDE will help putting annotation in the right place.

Note that DI users now must use lateinit var

AFAIU, it is not true. You can use var for dependency injection, you just have to make it nullable and assign null on initialization.
I also want to note that kotlin-first frameworks do not need this feature at all. With Koin, one does just val service: Service by inject().

[lppedd]

@InversionSpaces

Personally, I don't see why making it one-symbol-change is such a big concern: the IDE will help putting annotation in the right place.

There is already a problem here: the fact you need to rely on an IDE's inspection. Since we also have LSP users now, maybe if this quickfix is injected by the compiler frontend, it's ok. Still not optimal but ok.

AFAIU, it is not true. You can use var for dependency injection, you just have to make it nullable and assign null on initialization.

No one does this. It propagates nullable value quirks everywhere and it becomes a PITA.

Also want to note that kotlin-first frameworks do not need this feature at all.

I can agree with you, but realistically speaking we have Spring and Quarkus at the top of the list, and Kotlin should try to be as easy to use as possible, especially for those folks that promote or are transitioning from Java.

[lppedd]

@InversionSpaces any update on this btw? I still believe this is an essential UX improvement.

[InversionSpaces]

@lppedd No updates, at this point we are still committed to act on feedback from experimental release regarding this inconvenience.

[InversionSpaces]

Hello!

During an extended internal discussion, we reassessed our compilation strategy for lateinit val properties.
To make them thread-safe, we initially planned to mark the backing field as volatile and update it using AtomicReferenceFieldUpdater. However, this approach has two significant drawbacks:

• Hidden synchronization semantics: Accessing a lateinit val would establish happens-before relationships that affect other user code. This behavior differs significantly from that of other Kotlin properties and could hide places where the user needs to add explicit synchronization.
• Poor performance and stability: AtomicReferenceFieldUpdater adds significant performance overhead, which R8 only recently mitigated (see this). It has also caused crashes on some Android systems (see issue).

For the experimental release, we have therefore decided not to make lateinit val properties thread-safe.
Instead, generated code will use a non-volatile backing field guarded by checks in both the getter and setter.

Consequently, multiple unsynchronized writes from different threads may violate the assign-once guarantee.
We believe such errors are likely to be detected during testing.

Because lateinit val properties are not thread-safe, smartcasts for them would be unsound.
We have therefore also decided not to support smartcasts for lateinit val properties in the experimental release.

We welcome user feedback and may consider the following improvements:

• Allow users to explicitly opt in to thread-safe code generation for lateinit val properties.
  Smartcasts for these properties could then be supported safely.
• Support smartcasts for non-thread-safe lateinit val properties,
  accepting that they may be unsound in a multithreaded environment.

See the updated KEEP for details.

[kyay10]

Support smartcasts for non-thread-safe lateinit val properties,
accepting that they may be unsound in a multithreaded environment.

My vote goes to this 100%. Thread safety issues can be mitigated in other ways, and are unlikely to affect common use cases of this feature.

[CLOVIS-AI]

I'm kind-of reticent to having potentially-unsound smart casts, but since it's unlikely to affect real code, I think it'd be worse not have smart casts at all (at that point lateinit val wouldn't be that much more useful than the status quo).

[qwwdfsad]

I would strongly vote for smartcasts on the thread-unsafe lateinit val.

We have plenty of places with unsound smartcasts in corner-casy places that imply a developer mistake (covariance and generics, intiaillization order dependency for nulls, incorrect contracts etc.).

For double-initialization mistake, we basically expect the following:

• A developer, by accident, initialized lateinit val twice
• Such an initialization is racy
• At no point of time, the regular setter check caught that (which should fire quite often for non thread-heavy programs)
• The value being set is of different types
• The smartcast happens in a place where it can read the first, then the second value, and it matters (also: compiler optimizations and stack spilling)

So, to prevent that from happening (and I would argue that similarly to intiailization order NPEs, that's an obvious bug that will be caught on the first run or two; contrarily, it is much harder to make), we are basically taking away quite a significant QoL improvement, which is a net loss in my books