``` class CliOption2<T>(additionalPropert...

# getting-started

[sreich]

class CliOption2<T>(additionalProperties: MutableMap<String, Any>) {
        val value by lazy {
            val t = additionalProperties[cliOption.opt]!! as? T
            t ?: throw NotImplementedError("cli option could not be casted")
            t

}

how can i fix the cast warning here? I thought me throwing something if it fails would work. Why is it still considered unsafe and how can i fix this?

[ephemient]

generic types are erased at runtime, so as? T doesn't actually know what T is and always succeeds even if it's not correct

[Ruckus]

In general, types are effectively replaced by their upper bound at runtime, so T in your case is effectively Any?, and since everything is indeed Any?, it's always true.

[sreich]

ah, that's a good expalanation

[sreich]

so there's no way around this except to add a suppress warning?

[sreich]

i thought kotlin had fixes for type erasure, but it looks like those only really apply for Array types

[Ruckus]

Kotlin has reified generics, but that only applies to functions that are inlined at compile time, and thus the generic doesn't exist at runtime.

[sreich]

i was thinking about reified

[Ruckus]

As far as a way around it, there are potential options if you rework your types to include more information, but that's only if you have that information available somehow.

[ephemient]

Array is magical on JVM in general, for historical reasons - T[] is a unique type for every (erased) type T, including other array types. but that was in Java before generics, and when they added generics they didn't change any bytecode semantics, so that magic doesn't apply to anything other than arrays

[ephemient]

if you passed a val kclass: KClass<T> then you could use that to check isInstance. (you'd still have an unsafe check but at least you'd have a justifiable reason to suppress)

[sreich]

ah that is a good point, Arrays are unique in jvm

[ephemient]

only inline functions can be reified, not classes or constructors, so given this code structure, you don't have many other options

[sreich]

well in that case, i could just change the prop to be an inline function right?

[ephemient]

not sure what you mean

[sreich]

the val value by lazy could be changed to a inline getValue() {}

[sreich]

with a reified <T> i guess. right?

[ephemient]

the type would be determined by the callsite

[ephemient]

if that makes sense for you, then sure

[sreich]

gotcha