如何在 Swift 中为泛型类型添加类型方法？

Question

I am trying to add a type (aka static) method to a generic class in Swift. Here is the code.

class StateArchive<T> {
    class func emptyAllArchives() {
        // do something
    }
}

// the compiler emits an error: "Argument for generic parameter 'T' could not be inferred"
StateArchive.emptyAllArchives()

I can get the above code to compile by providing the type in place of T like so:

StateArchive<AnyObject>.emptyAllArchives()

This looks awkward, however. Initially I though that the reason for this could be that one could create a class variable with type T. A quick test in the playground revealed that the compiler emits a message saying:

"Class stored properties not yet supported in generic types".

Does anyone know how to create a type method in a generic type and let the client call this method without providing the type in place of T?

Answer 1

When encountering an issue with generics that doesn't work the way expect it's often useful, to help understand the issue, to think about what would happen if you replaced a placeholder with different concrete types.

So for example, suppose you defined the following (this won't compile for the reason you give, but imagine it did):

class C<T> {
    static var a: [T] = []

    static func addElement(i: T) {
        a.append(i)
    }
}

Really, when you write class C<T> , you aren't writing a class. You're writing a blueprint for an infinite number of possible classes – C<Int> , C<String> , C<AnythingElse> .

Under these circumstances, suppose you wrote C.addElement(1) – so T would be Int . Then later, you wrote C.addElement("one") . Would Ca now contain one item, or two? What would the type of a be?

Probably the most reasonable answer would be that there would be a C<Int>.a with one element, and a C<String>.a with one element. But this could get very confusing, and it doesn't seem like there are use cases to justify this kind of functionality.

Generally, static methods and properties are best used rarely, and you may find you are better off with non-static members and methods, combined with a singleton pattern (or maybe not even that). If you still find the need for static-like functions, you may be better off using a generic free function (eg func emptyArchive<T: C>(c: C) { } ).

Answer 2

The other answer is correct in its explanations, but you can in fact get the behavior you intuitively expected with this:

extension StateArchive where T == Any {

    static func emptyAllArchives() {
        // do something
    }
}

// works as expected
StateArchive.emptyAllArchives()