A modern programming language that makes developers happier.

kotlinlang

Is it a good practice for library (or any generic API) to return `StateFlow` or `SharedFlow` if the particular flow behaves state-like or share-like? Or is it better to stick to `Flow` to be more generic? I was advised to do the latter, but oftentimes I find it useful to do something like `onSubscription` which is unavailable for `Flow` and having to do `stateIn` / `shareIn` when I know that underlying code already has `StateFlow`/`SharedFlow` somehow feels wasteful.

StateFlow/ SharedFlow are both interfaces so there's no strong reason not to use them as a return type if it makes sense for your contract

Does very much depend on how you want the API to be used though

Note that in general having the consumer call stateIn / shareIn is not equivalent to allowing them to monitor the upstream flow

Yeah, sometimes I just want to explicitly specify that some flow has properties of "state": i.e. it will have values conflated and always emit last one on subscribe, and sometimes I want to specify that flow is "event-like", i.e no deduplication and no value on subscribe.

And I'd like to be able to communicate this through types rather than through docs.