Hello, what is the difference between

private val _state = MutableStateFlow<Foo>(Foo())
val state = StateFlow<Foo> get() = _state

and

private val _state = MutableStateFlow<Foo>(Foo())
val state = StateFlow<Foo> = _state

? Jetbrains and Google use the first form in their documentation, but isn't a

val

read-only regardless of whether it is specified as only having a getter or not?

The second form creates a separate backing field that stores the same instance as _state, as well as a getter for that backing field. The first form only creates a getter that wraps the _state field.

Yeah…. Didn’t understand it either why

get() =

was used and not plain `=`…

Oh! I didn't think of the generated code

so which one is better?

To clarify, neither the val nor the getter are necessary to prevent external users from mutating the contents of

state

val state: StateFlow<Foo> = _state

is a bit more performant… the

get()=

is not needed, in my opinion

Why do you think that’s more performant?

Why do

get()=

if

=

works as well? A plain field assignment seems simpler to me

It’s really an implementation detail, but the latter requires an extra useless field in your class, which makes your object sizes slightly larger in theory (I’m not sure if this gets optimized out by R8).

?? I thought it was

private val _state = MutableStateFlow<Foo>(Foo())
val state: StateFlow<Foo> get() = _state

vs

private val _state = MutableStateFlow<Foo>(Foo())
val state: StateFlow<Foo> = _state

and the 2nd one seems sufficient… why the

get()

?

// With get() = 
private val _state: String 
fun getState(): String = _state

vs

// Without get() =
private val _state: String
private val $_state: String = _state
fun getState(): String = $_state

Ah yes, I see. The

get()=

won’t create yet another backing field.

In this case, the behavior is the same. If the backing field were mutable, then the two forms would have meaningfully different behavior. So there’s some different intent communicated as well.

Thank god JetBrains is working on a way to have a private facing and public facing type, removing the need for the odd backing field solution.

Ultimately, in this case, it almost certainly doesn’t matter, for performance or otherwise.