I am looking at docs and see this. Why wouldn't

isEmpty

be a function? Also wouldn't the value stored in

isEmpty

never be referenced?

In this case property doesn’t have a backing field.

aight thanks

What's the recommended pattern here, btw? Myself, when I see that something is declared a

val

, and I know that the type that the

val

is referencing is deeply immutable (like a

Boolean

), I want to believe that what I receive from accessing the property is the same every time. Of course, with the case of custom getters like this, it's not necessarily the same every time, like if this is a property defined in a mutable list. Essentially, what I'm wondering if it's “OK” to write code like this, where the deeply immutable “contents” of a

val

can change from each invocation of the getter.

well, it is in official docs, so I would guess so

Sure, but a “pure lambda” wouldn't have that same problem, right?

we aren't assigning different getter logic, so it doesn't make sense to have it

var

(imo)

No, I'm thinking that in cases like this it might make “more sense” to have a function

isEmpty(): Boolean

instead, perhaps?

oh, I see

Of course,

val

does not by any means suggest that the thing referenced is immutable, but that's another topic. One could, for instance, have a

val names: MutableList<String>

.