Flow hierarchy and why optional flow types?

[wkornewald]

Since the SKIE plugin knows about nullability, why does it need separate classes for nullable/optional flows? Internally it can still track if the original type was nullable or not and treat it accordingly. This seems like unnecessary complication.

Also, why doesn't SkieSwiftMutableStateFlow inherit from SkieSwiftStateFlow? This would make it easier for Swift code to instantiate a MutableStateFlow and pass that to Kotlin (which might only expect a StateFlow).

And why isn't there any built-in mechanism to instantiate flows? We had to create our own wrapper class.

[FilipDolnik]

Hi!

Since the SKIE plugin knows about nullability, why does it need separate classes for nullable/optional flows? Internally it can still track if the original type was nullable or not and treat it accordingly. This seems like unnecessary complication.

Even though SKIE knows about the nullability (which is how it can determine which of the two classes to use), it has to pass that nullability information to Swift somehow. The reason why using the two classes is the only way to do so is complicated. The simplified explanation is that you cannot write something like Flow<Int?> in Obj-C, so there is no other reasonable way to pass that information.

Also, why doesn't SkieSwiftMutableStateFlow inherit from SkieSwiftStateFlow? This would make it easier for Swift code to instantiate a MutableStateFlow and pass that to Kotlin (which might only expect a StateFlow).

Because the SkieSwiftStateFlow is a final class (and it must be due to how Objective-C bridging works). Therefore, you can't inherit from it.

And why isn't there any built-in mechanism to instantiate flows? We had to create our own wrapper class.

Can you please share an example of the wrapper? I'm not sure what you mean.

If you want to instantiate flows from Swift, you should be able to use regular Kotlin functions like MutableStateFlow(value: T) or flowOf(). However, I'm aware that you can't use flow { } easily because there is no support for passing suspend functions back to Kotlin (if I remember correctly), but that would be a separate feature. You also can't convert AsyncSequence back to Flows. That is also a separate feature that we have somewhere in our backlog but it has a low priority because we weren't able to find that many convincing use cases for it yet.

[wkornewald]

Hi!

Since the SKIE plugin knows about nullability, why does it need separate classes for nullable/optional flows? Internally it can still track if the original type was nullable or not and treat it accordingly. This seems like unnecessary complication.

Even though SKIE knows about the nullability (which is how it can determine which of the two classes to use), it has to pass that nullability information to Swift somehow. The reason why using the two classes is the only way to do so is complicated. The simplified explanation is that you cannot write something like Flow<Int?> in Obj-C, so there is no other reasonable way to pass that information.

The Swift flows are actual Swift classes though. So I don't see any reason why the compiler can't generate code that (even with forced type conversions or other magic) turns the Obj-C type into the proper Swift type, including nullability info.

Also, why doesn't SkieSwiftMutableStateFlow inherit from SkieSwiftStateFlow? This would make it easier for Swift code to instantiate a MutableStateFlow and pass that to Kotlin (which might only expect a StateFlow).

Because the SkieSwiftStateFlow is a final class (and it must be due to how Objective-C bridging works). Therefore, you can't inherit from it.

Could the bridging be done with generated code instead then? In some other discussion there was also some limitation of the built-in bridging mechanism and the option of going with a code generation based solution was provided, though it's more complicated.

And why isn't there any built-in mechanism to instantiate flows? We had to create our own wrapper class.

Can you please share an example of the wrapper? I'm not sure what you mean.

If you want to instantiate flows from Swift, you should be able to use regular Kotlin functions like MutableStateFlow(value: T) or flowOf(). However, I'm aware that you can't use flow { } easily because there is no support for passing suspend functions back to Kotlin (if I remember correctly), but that would be a separate feature. You also can't convert AsyncSequence back to Flows. That is also a separate feature that we have somewhere in our backlog but it has a low priority because we weren't able to find that many convincing use cases for it yet.

When calling MutableStateFlow the generics are lost and the value is Any?. So that's not usable for us. That's why I've created classes which contain MutableStateFlow and StateFlow attributes which keep the generics.

[FilipDolnik]

The Swift flows are actual Swift classes though. So I don't see any reason why the compiler can't generate code that (even with forced type conversions or other magic) turns the Obj-C type into the proper Swift type, including nullability info.

Could the bridging be done with generated code instead then? In some other discussion there was also some limitation of the built-in bridging mechanism and the option of going with a code generation based solution was provided, though it's more complicated.

Yes, generating Swift wrappers for every function is a possible alternative. However, it's far from simple, and it would create new kinds of limitations. For example, you can't generate these wrappers for generic classes (it's the same problem as with suspend functions), and you also can't make them overridable (again, same as with wrappers for suspend functions).

But the main reason we haven't chosen this option is the amount of work required to implement it. Implementing basically anything in SKIE is very time-consuming, and we are resource-constrained, so we have to carefully weigh the benefits and costs of each feature. There are many other interesting features that we want to focus on.

That being said, we might iteratively get to a point when SKIE generates wrappers for all (or almost all) functions for different reasons, and at that point, it might make sense to consider this option.

When calling MutableStateFlow the generics are lost and the value is Any?. So that's not usable for us. That's why I've created classes which contain MutableStateFlow and StateFlow attributes which keep the generics.

Hm, we haven't considered this issue because we don't use Flows this way in our applications. I think that it might make sense for us to provide some lightweight runtime wrappers for the coroutines library that would reimplement these functions for Swift.

So, for example, we could have something like:

public func MutableStateFlow<T>(value: T): SkieSwiftMutableStateFlow<T> { ...

btw you can write these function wrappers manually in the meantime and use the new Swift code bundling in SKIE to put them into the Kotlin framework.

[TadeasKriz]

The Swift flows are actual Swift classes though. So I don't see any reason why the compiler can't generate code that (even with forced type conversions or other magic) turns the Obj-C type into the proper Swift type, including nullability info.

ObjC->Swift bridging is essentially limited to 1:1 relationship between an ObjC class and a Swift class/struct. So we can’t map both optional and non-optional ObjC flows to a single Swift class that could handle nullability in its generic parameter.