How to handle Generics in Environment Clients?

[cheeseonhead]

Normally if I was building a generic storage wrapper, I might have something like this:

struct Storage {
  func save<T: Codable>(_ key: String, value: T)

  func load<T: Codable>(_ type: T.Type) -> T
}

But for Clients in the Environment, we have seen approaches of converting the methods into function properties so their implementations can be dynamically created.

However, properties don't work with generics, so the following can't work:

struct StorageClient {
  var save: (String, T) -> Void
  var load: (T.Type) -> T
}

I could lift the generic to the type itself:

struct StorageClient<T: Codable> {
  var save: (String, T) -> Void
  var load: (T.Type) -> T
}

But then that means in the domain code, in the Environment struct, I would need a StorageClient for each type I want to store:

struct TestEnvironment {
  var storageClientA: StorageClient<A>
  var storageClientB: StorageClient<B>
}

Is there a better way to deal with this type of stuff?

[JacksonUtsch]

Just recently had the same question come up for me to do with read/write to a keychain client. I think existential types could have a role here but they are not yet developed enough. Example:

struct Storage {
  var save: (any Encodable)
  var load: (any Decodable) -> Data
}

Although, still unsure about the load return value. This would propagate deciding the return type.

[mbrandonw]

You can represent your storage client as dealing with plain Data and then create helper methods on the client for dealing with more structured data such as Codable:

public struct StorageClient {
  var _save: (String, Data) -> Void
  var _load: (String) -> Data

  public func save<T: Encodable>(key: String, value: T) throws {
    self._save(key, try JSONEncoder().encode(value))
  }
  public func load<T: Decodable>(key: String, as type: T.Type) throws -> T {
    try JSONDecoder().decode(T.self, from: self._load(key))
  }
}

[cheeseonhead]

This totally makes sense. The takeaways for me here is that just make the live implementation deal with the type erased type and build wrappers around it to deal with structured data. Sorry if I'm confusing my terminologies here.

But what happens for types that I'm not certain if it can be type erased or not? For example this: https://developer.apple.com/documentation/groupactivities/groupsession

Would I be able to create a general purpose SessionClient to return a specific type of GroupSession<ActivityType>?

Ideal API:

struct SessionClient {
  func sessions<Activity: GroupActivity>() -> Effect<GroupSession<Activity>, Never>
}

This will be driven by GroupActivity framework's GroupSession<Activity>.sessions() method, which itself is also generic, but I can't find a way to create a function property that can call this method.

Is this potentially a limitation?