Apparently it’s OK to pass null down a Flow, and F...

# announcements

[grahamborland]

Apparently it’s OK to pass null down a Flow, and Flow is intended to be compliant with the Reactive Streams spec. But the Reactive Streams spec disallows null, which is why RxJava 2 had that massive breaking change. I’m getting confused about something… why can a Flow handle null, but Rx2 can’t?

[Zach Klippenstein (he/him) [MOD]]

I suspect the RS spec disallows nulls because they’re dangerous in languages like objc, Java, and JavaScript. Disallowing nulls at the boundaries of the rx apis encourages writing safer, null-free code, and enforcing that constraint at runtime at those boundaries helps catch potentially sneaky bugs earlier (eg if you get a null out of a complex stream it might not be obvious where it came from, but if you get an error as soon as you try sending a null into the stream it’s more obvious).

It would seem to me that, by supporting nulls, flow diverges from the reactive stream spec. But it does so for pragmatic reasons: because kotlin can handle nulls safely with the type system, that danger is gone and it’s useful to be able to use them. Probably the team decided that the usefulness outweighed strict adherence to the spec.

[Zach Klippenstein (he/him) [MOD]]

Also note that Flow’s integration with the Reactive Streams library’s types (eg Publisher) are only defined for non-nullable element types, so you can’t accidentally write code that violates the RS nullability restriction that other compliant libraries might enforce.

[grahamborland]

Ah, that’s interesting. The coroutines-rx2 adapters (for example) just won’t allow you to compile code that’s unsafe.