(I don't want to use a sealed class for just this ...

# announcements

[dead.fish]

(I don't want to use a sealed class for just this emptiness case)

[Ruckus]

Personally I'd recommend it. Why don't you want to?

[Ruckus]

Or, do you really need such an "empty" PaginatedList<V, T>, or could you not use a nullable PaginatedList<V, T>? instead and filter out nulls?

[dead.fish]

hrm... have to think about that

[dead.fish]

I really like to work without nullable types, so I try to avoid them where possible and use default objects instead

[Ruckus]

I agree, but it's important to remember that Kotlin is a null-safe language, not a non-null language (like Rust). If the problem at hand has a clear use case for missing/empty/optional values, nullability is the way to go, and Kotlin's language features make it pleasant and safe to do so.

[Ruckus]

There's no reason to create a whole new instance to represent "this doesn't exist", just use the built in concept of not existing: null.

[Ruckus]

(It's worth noting that most languages that have no concept of null (like Rust) have some sort of Optional type that is optimized by the compiler to a nullable reference, so even they use it under the hood.)

[dead.fish]

ok, thanks for the detailed explanation - that was helpful! I'll probably wrap my head around making the thing nullable then.