SharedFlow doesn't have same parameters as in constructor function

[Mr3zee]

trafficstars

MutableSharedFlow function has three parameters:

• replay: Int
• extraBufferCapacity: Int
• onBufferOverflow: BufferOverflow

MutableSharedFlow interface, in turn, says in its documentation that an instance can be created using this function. SharedFlow relays on these parameters. However, they are not a part of the interfaces and are present only as parameters to the constructor function. They are part of the SharedFlowImpl class, which is internal in kotlinx.coroutines.core.

This makes it hard to properly serialize SharedFlows in the kotlinx.rpc library.

Can you, please, advise what can be done to improve this situation? We need a multiplatform approach to retrieve these parameters, however, we don't have one now

[qwwdfsad]

Could you please elaborate on the lifecycle of such a SharedFlow? E.g. the particular use-case how and why it is serialized and what it represents to clients etc.

[dovchinnikov]

@Mr3zee Why would you want to serialize shared flows in the first place?

[Mr3zee]

Well, we wanted to send flow in RPC. But recent design session concluded that we don't want to do that anymore. However, I would still say that this is a valid problem. Especially now, when inheriting SharedFlow is prohibited.

[dkhalanskyjb]

@Mr3zee, still, why would one need to do that? To me, a SharedFlow only makes sense inside the process where it was created, and sending it somewhere else feels meaningless. Could you provide a specific example of a use case?

[Mr3zee]

@dkhalanskyjb exactly the point, which invalidates the initial reason for this request.

However, as I mentioned, I still think that, disconnected from the original problem, having parameters in the constructor function, that function being the only proper way to create a SharedFlow instance, and not having the ability to access them - is unfortunate, and I suggest to consider providing this ability. But it is no longer required by our library

[dkhalanskyjb]

Got it, thanks! In general, the main reason not to expose any such parameters is to avoid tying our hands too much when it comes to evolving the library further. It's a conflict between two different abstract versions of the future:

• What if down the line, we decide to change how SharedFlow works in a way that's incompatible with the current parameters, while still ensuring that constructing SharedFlow with the existing constructor is possible? (For example, we could introduce several mutually incompatible SharedFlow implementations)
• What if down the line, some user will want to access extraBufferCapacity and be disappointed that we don't provide this functionality out of the box?

We don't know which of the two will happen (or if something will happen at all), so the decision not to add the unnecessary APIs wins by default: we can add them at any time when someone explains that they are useful, but we can't easily remove them once we add them.

So, closing the issue for now. If someone provides a use case for these parameters down the line, we'll reopen this / open a new issue.