POP, Generics, Associated Types, and Ponies

hmlongco · 2022-12-01T04:38:56.754Z

So I have a little dependency injection library I wrote called Factory and I was working on a few examples of how to use it and I ran into a problem.

This is, however, going to take a little setup.

All of us, at one point or another, have probably defined a protocol and associated services something like the following:

protocol AccountLoading {
    func load() -> [Account]
}

struct AccountLoader: AccountLoading {
    func load() -> [Account] {
        return [Account()]
    }
}

Note that my protocol and loader return straight, non-async values just to keep the code simple.

With Factory I can register a service that uses both of these for later injection.

extension Container {
    static let accountLoader = Factory<AccountLoading> { AccountLoader() }
}

Now, with the protocol in place, I can also create a mock version and use that for previews, mocking, and testing.

struct MockAccountLoader: AccountLoading {
    func load() -> [Account] {
        return [Account()]
    }
}

func setupMocks() {
    Container.accountLoader.register { MockAccountLoader() }
}

This is all good so far. I have my protocol. I have my service. I have mocks. But...

It would be nice if, instead of manually creating loaders and mock handlers, I could use some spiffy generic service providers. (This is where the problems begin....)

Let's say I have a couple of services like the following:

struct NetworkLoader<T> {
    let path: String
    func load() -> T {
        fatalError()
    }
}

struct MockLoader<T> {
    let data: T
    func load() -> T {
        return data
    }
}

That, in turn should let me revise my Factory and do...

extension Container {
    static let accountLoader = Factory<AccountLoading> {
        NetworkLoader<[Account]>(path: "/api/accounts")
    }
}

But I get an error about how NetworkLoader doesn't conform to AccountLoading... because, well, it doesn't. I get that. I have a load() -> [Account] function, but that doesn't automatically make it conform to the protocol.

So let's add that conformance to the loader and to the mock loader as well.

extension NetworkLoader<[Account]>: AccountLoading {}
extension MockLoader<[Account]>: AccountLoading {}

Success! But... this is a little clunky. I can use my generic services, but I still have to do the following for each and every type I want to work with.

protocol AccountLoading {
    func load() -> [Account]
}

extension NetworkLoader<[Account]>: AccountLoading {}
extension MockLoader<[Account]>: AccountLoading {}

It would be nice if I could bypass the need for all of that. Maybe a generic protocol is in order......

protocol TypeLoading {
    associatedtype T
    func load() -> T
}

extension NetworkLoader: TypeLoading {}
extension MockLoader: TypeLoading {}

And then create my Factory using the generic type...

extension Container {
    static let accountLoader = Factory<TypeLoading<[Account]>> {
        NetworkLoader<[Account]>(path: "/api/accounts")
    }
}

But sadness. Swift doesn't approve of this and tells me that I can't specialize protocol type TypeLoading.

Bummer.

Now, I could do the following...

protocol NewAccountLoading: TypeLoading where T == [Account] {}

extension NetworkLoader<[Account]>: NewAccountLoading {}
extension MockLoader<[Account]>: NewAccountLoading {}

extension Container {
    static let accountLoader = Factory<any NewAccountLoading> {
        NetworkLoader<[Account]>(path: "/api/accounts")
    }
}

But, similar to how things worked earlier, I still have to define the NewXXXLoading protocol and extensions for each and every type I want to use.

The code I need to write is getting smaller, but that's still boilerplate code I'd simply prefer to avoid.

I could ignore protocols altogether and go classic OOP...

class AbstractLoader<T> {
    private init() {}
    func load() -> T {
        fatalError()
    }
}

class NetworkLoader<T>: AbstractLoader <T> {
    // implementation
}

class MockLoader<T>: AbstractLoader <T> {
    // implementation
}

Which at least gives me a clean Factory specification without the need for extra protocol and extension definitions.

extension Container {
    static let accountLoader = Factory<AbstractLoader<[Account]>> {
        NetworLoader<[Account]>(path: "/api/accounts")
    }
}

But in this day and age that feels... well... old. And not very Swifty.

Which brings me, finally, to my question. Is something like the following even possible given the state of Swift generics?

extension Container {
    static let accountLoader = Factory<TypeLoading<[Account]>> {
        NetworkLoader<[Account]>(path: "/api/accounts")
    }
}

What am I missing?

That's all I want for Christmas. A simple definition without extra protocols and extensions.

Well. maybe that and the pony....

hmlongco · 2022-12-01T04:43:01.428Z

BTW, the definition of a Factory could be expressed like this...

public struct Factory<T> {
    let factory: () -> T
    public init(factory: @escaping () -> T) {
        self.factory = factory
    }
    public func callAsFunction() -> T {
        factory()
    }
}

There's a lot more to it, of course, but basically it's a typed struct.

jrose · 2022-12-01T04:51:41.482Z

I think you can do this, before Christmas even, if you give your protocol a primary associated type. Though you’d then make that explicit by spelling it any TypeLoading<[Account]>.

hmlongco · 2022-12-01T06:23:24.792Z

Ohhhh. New in 5.7!

protocol TypeLoading<T> {
    associatedtype T
    func load() -> T
}

extension NetworkLoader: TypeLoading {}
extension MockLoader: TypeLoading {}

extension Container {
    static let typedAccountLoader = Factory<any TypeLoading<[Account]>> {
        NetworkLoader<[Account]>(path: "/api/accounts")
    }
}

Unfortunately... "Runtime support for parameterized protocol types is only available in iOS 16.0.0 or newer"

jrose · 2022-12-01T06:24:04.434Z

Swift 5.7: Runtime parametrized protocols Using Swift

Runtime casting to a parameterized protocol is limited to the latest OSes because it requires runtime support not otherwise available. You can use parameterized protocols in other ways and still back deploy.

hmlongco · 2022-12-01T06:29:44.910Z

Swift 5.7: Runtime parametrized protocols

You can use parameterized protocols in other ways and still back deploy.

Other ways?

jrose · 2022-12-01T07:08:40.860Z

You’re not casting as? any TypeLoading<Whatever>, so there should be no dependency on iOS 16.

hmlongco · 2022-12-01T14:22:41.197Z

May be missing what you're saying, but the following simply gives the same iOS 16 error...

extension Container {
    static let typedAccountLoader = Factory<any TypeLoading<[Account]>> {
        NetworkLoader<[Account]>(path: "/api/accounts") as any TypeLoading<[Account]>
    }
}

The error is on Factory<any TypeLoading<[Account]>>. It's not within the closure.

jrose · 2022-12-01T16:27:15.617Z

I’m sorry, my mistake. It looks like you will need a non-generic wrapper for now, even if that wrapper doesn’t do anything:

struct AccountLoading {
  var inner: any TypeLoading<[Account]>
}

let typedAccountLoader = Factory<AccountLoading> {
  AccountLoading(inner: NetworkLoading("api/accounts"))
}

Not ideal, but possibly still better than repeating the protocol?

How to use SE-0353 features? (Constrained Existential Types) Discussion

Note that you can use constrained existentials in limited ways on older deployment targets, and those ways are powerful enough that you can almost get to feature parity, just in a less convenient way than you can on newer deployment targets. In particular, you can declare parameters, variables, properties, and return values as having a constrained protocol type. So while the restrictions mean you can't have a generic type argument that's a constrained existential type (and therefore you can't …

John_McCall · 2022-12-01T18:01:18.950Z

The wrapper doesn't need to be non-generic, for what it's worth; you could have:

struct AccountLoading<T> {
  var inner: any TypeLoading<T>
}

The constraint is just that you can't use a parameterized protocol type as a generic argument itself without the runtime support.

hmlongco · 2022-12-02T00:28:02.856Z

May be the best choice. That's not really just an AccountLoader though...

protocol TypeLoading<T> {
    associatedtype T
    func load() -> T
}

struct AnyLoader<T> {
    let wrapped: any TypeLoading<T>
    init(_ wrapped:  any TypeLoading<T>) {
        self.wrapped = wrapped
    }
    func load() -> T {
        wrapped.load()
    }
}

extension Container {
    static let accountLoader = Factory<AnyLoader<[Account]>> {
        AnyLoader(NetworkLoader(path: "/api/accounts"))
    }
}

At least this way I don't have to redefine a new protocol each and every time I want to use it.

I sort of feel like I got my pony... but now have to wait a couple of years before he's old enough to ride...

afarnham · 2022-12-02T15:49:49.085Z

What about foregoing protocols and just making TypeLoading a datatype wrapper around a function?

struct Account {}

struct TypeLoading<T> {
    var load: () -> T
}


public struct Factory<T> {
    let factory: () -> T
    public init(factory: @escaping () -> T) {
        self.factory = factory
    }
    public func callAsFunction() -> T {
        factory()
    }
}

struct NetworkLoader<T> {
    let path: String
    func load() -> T {
        fatalError()
    }
}

extension NetworkLoader where T == [Account] {
    static let accounts = NetworkLoader(path: "/api/accounts")
}

struct MockLoader<T> {
    let data: T
    func load() -> T {
        return data
    }
}

struct Container {}

extension Container {
    static let accountLoader = Factory<TypeLoading<[Account]>> {
        .init(load: NetworkLoader.accounts.load)  //The .init is TypeLoading<[Account]>.init
    }
}

hmlongco · 2022-12-02T16:54:19.900Z

Umm... if you're going to do that then you don't even need the wrapper.

typealias LoadFunction<T> = () -> T

extension Container {
    static let accountLoader = Factory<LoadFunction<[Account]>> {
        NetworkClassLoader<[Account]>(path: "/api/accounts").load
    }
}

The parameterized protocol type is closest to what I want to do... but in typical Apple fashion I just can't do it yet.