Proposal: Split async methods into separate interfaces?

[JesseTG]

Some storage backends only support synchronous APIs. Some only support asynchronous APIs. Would it be possible to divide interfaces that have methods for both into synchronous and asynchronous versions?

[dre0dru]

@JesseTG Hello! Can you please provide more info on how you view this? As I understand you are talking about IFileStorage and IPlayerPrefsStorage and they support async and sync API which is defined mostly by underlying ISerializationProvider. Default package implementation (UnityJsonSerializationProvider) indeed provides only sync API for serialization, but some serialization libraries like UT8Json provide async API, too. Also IDataTransofrm implementations that can be used with ISerializationProvider also have async API.

Right now my only thoughs are something like this:

interface IFileStorage {
//sync API + utility methods
}

interface IAsyncFileStorage : IFileStorage {
//addintional async API
}

class FileStorage : IAsyncFileStorage {
// both async and sync implementation
}

The same for IPlayerPrefsStorage.
This way, e.g., you can bind instance to sync or async interface.
Maybe you can provide use case where you need that kind of separation if I misunderstood you?

[JesseTG]

No, you understand me correctly.

I don't have a specific use case right now, since I happen to almost exclusively use asynchronous storage APIs in my project, but I'm trying to think a step ahead. Maybe just keep this idea in your back pocket? Honestly, if you had discussions enabled I'd have mentioned this there instead of opening a ticket.