I have a question regarding null-safety, I think n...

# language-evolution

[Shaun Wild]

I have a question regarding null-safety, I think nullable types are awesome, and it really allows you to define what is, and what might not have a value set, awesome.

One scenario where this kinda feels janky for me, is when you know a field to not be nullable, or even a number of fields, but you still have to either use !! everywhere, use null checks, or ?.let etc, my question is: Is there a better way to handle this?

[Shaun Wild]

A case in point for me: I am using a data class, that is intended to be poolable, I know that at certain points, the data within said class will not be null, so I don't want to have to litter my code with null-safety checks.

[Shaun Wild]

for example:

@Serializable
data class AbilityPacket(
    var abilityId: Int? = null,
    var targeting: AbilityTargeting? = null,
    var entity: Entity? = null
) : NetworkPacket {
    override fun reset() {
        abilityId = null
        targeting = null
        entity = null
    }
}

[Shaun Wild]

(NOTE: I am not asking how is this done now, I'm starting a discussion about how this language could evolve to better suit this use-case)

[Shaun Wild]

Due to proper encapsulation, I know use sites of this class will definitely have all fields set, but I still have to use null safety anyway.

[Shaun Wild]

One idea I had, why not enable use of the Java-nullable type, for example:

data class AbilityPacket(
    var abilityId: Int! = null,
    var targeting: AbilityTargeting! = null,
    var entity: Entity! = null
) ......

which would allow us to decide whether the usage of this type is null-safe or not.

[Youssef Shoaib [MOD]]

There's lateinit, but obviously it doesn't help here because of your reset. You can use some property delegation to help out.

[Shaun Wild]

Yea lateinit is similar to this, it basically hands over the trust to the developer: "Make sure this property is available, before we access it"

[Shaun Wild]

This is more of a resetable lateinit

[Shaun Wild]

Could imagine something like this:

@Serializable
data class AbilityPacket(
    reinit var abilityId: Int,
    reinit var targeting: AbilityTargeting,
    reinit var entity: Entity
) : NetworkPacket {
    override fun reset() {
        ::abilityId.reset()
        ::targeting.reset()
        ::entity.reset()
    }
}

[ephemient]

class Packet(
    var _id: Int?,
) {
    val id: Int
        get() = _id!!

is possible of course, but the better design IMO would be to create a separate type with non-nullable properties, which you convert into after validation

[Shaun Wild]

Good idea

[phldavies]

You could potentially use a value class wrapping the type with nullable properties and expose them with non null inline properties.

[Shaun Wild]

How would that look?

[phldavies]

@JvmInline
value class PopulatedPacket(@PublishedApi internal val packet: AbilityPacket) {
    inline val abilityId: Int get() = packet.abilityId!!
    inline val targeting: AbilityTargeting get() = packet.targeting!!
    inline val entity: Entity get() = packet.entity!!
}

[Shaun Wild]

I thought value classes were only for primitive types

[phldavies]

https://pl.kotl.in/4gD-IeXk1 also for non-primitives

[Shaun Wild]

Oh nice

[Shaun Wild]

What even is the purpose of a value class lol

[Shaun Wild]

Is it to enrich a value but its all inlined