Reasons to bound Value for non-null values only?

[Prototik]

I want to ask for a reason to define Value as Value<T : Any>, not just Value<T>.

Is it intended? In my project i need to use Value for nullable types as well, and I don't see any practical reasons to define Value as Value<T : Any>.

Currently I forced to use it with custom wrapper (like Optional in java), but actually i don't need it if it will be just Value<T>.

[arkivanov]

Thanks for the question! This was already discussed a while ago. But it's good to repeat it here as well. Here is the copy of the original answer.

This is by design, due to how generics are exported to Swift. If we define it as Value<T>, then a non-null type (e.g. Value<String>) will be still nullable in Swift.

For the same reason they both are classes, and not interfaces. Because generics for an interface cannot be exported to Swift.

You can workaround nullable types by using something like data class Optional<T : Any>(val value: T?).

[Burtan]

Maybe its a good idea to add helper functions/classes into a separate module like the compose extensions for different use cases. In my case I'd like to use Kotlin flows, however their interop with swift is bad. Therefore I like your design decision with an own state holder (Value::class).
I think some extensions make it very easy to use flows with Value class to expose states to the ui.

@Composable
fun <T: Any> Value<Optional<T>>.subscribeAsState(): State<T?> {
    val state = remember(this) { mutableStateOf(value.value) }

    DisposableEffect(this) {
        val observer: (Optional<T>) -> Unit = { state.value = it.value }

        subscribe(observer)

        onDispose {
            unsubscribe(observer)
        }
    }

    return state
}

fun <T : Any> StateFlow<T>.asValue(scope: CoroutineScope): Value<T> {
    val mutableValue = MutableValue(value)
    scope.launch(Dispatchers.Main) {
        this@asValue
            .filterNotNull()
            .collect {
                mutableValue.value = it
            }
    }
    return mutableValue
}

fun <T : Any> Flow<T?>.asValue(scope: CoroutineScope): Value<Optional<T>> {
    val mutableValue = MutableValue(Optional<T>(null))
    scope.launch(Dispatchers.Main) {
        this@asValue
            .collect {
                mutableValue.value = Optional(it)
            }
    }
    return mutableValue
}

data class Optional<T : Any>(val value: T?)

Now use the mutableFlows in your components and expose them via .asValue(scope). The Optional data class allows nullable values and is hidden behind the subscribeAsState extension when using in compose.

    private val _exceptionsFlow = MutableStateFlow<Exception?>(null)
    override val exceptionFlow = _exceptionsFlow.asStateFlow().asValue(scope)

[arkivanov]

Thanks for ideas and use cases! For now I would regret from adding extensions for coroutines, because it's pretty difficult to have a preferred way of exporting data streams.

You can also export a Flow in the following way:

fun <T : Any> Flow<T>.export(context: CoroutineContext = Dispatchers.Main): ExportedFlow<T> = 
    ExportedFlow(source = this, context = context)

class ExportedFlow<out T : Any>(
    source: Flow<T>,
    private val context: CoroutineContext = Dispatchers.Main,
) : Flow<T> by source {
    
    fun subscribe(onNext: (T) -> Unit): Cancellation {
        val scope = CoroutineScope(context)
        scope.launch { 
            collect { onNext(it) }
        }
        
        return Cancellation(scope::cancel)
    }
}

fun interface Cancellation {
    fun cancel()
}

But we could add Optional I guess, I'll think about it, thanks again.