Why the restrictions on protocols with Self or associatedtype?

Question

While designing APIs, I run into this at every corner:

Protocol can only be used as a generic constraint because it has Self or associatedType requirements

What that means is that you basically can not use Self or associatedtype on protocol level if you ever plan to use the protocol type on its own -- otherwise the need for types to be generic themselves cascades out of control.

This is rather annoying (read: makes it next to impossible to design reasonable APIs, e.g. such that expose protocols but hide implementations). For instance, you can not have a simple data container protocol:

protocol DataContainer: Equatable {
    var id: Int { get }
    var content: Data { get }
}

The issue is that Equatable requires static function == which is, of course, expressed using Self. Therefore, you can not have a type like [DataContainer], or any number of other natural things. I first ran into it with groups (arrays) of users (which could be of one of three different types).

The "official" recommended "solution" is to have delegating/wrapper structs that eliminate the type variable, like AnyDataContainer. This feels like a rather silly, hacky workaround, not proper API design.

I honestly don't get why the type system has this restriction. What are the reason? Why can't the compiler implicitly create AnyP for every protocol P to work around it?

Answer 1

Here is one reason I can think of, which actually does not need an arcane setup either. Building on the example from the question, say we could have code like this:

func contained(element: DataContainer, in list: [DataContainer]) -> Bool {
    for elem in list {
        if elem == element {
            return true
        }
    }
    return false
}

The Swift compiler wants to statically dispatch ==; but it can't! There is no single implementation it can pick up; every array element may have its own type and therewith implementation of ==, and element may have a completely different one. The compiler therefore forbids the code at hand.

---

Two additional thoughts.

1. I'd argue that the compiler to too defensive. The following code could be compiled easily, for instance:

   func contained(id: Int, in list: [DataContainer]) -> Bool {
       for elem in list {
           if elem.id == id {
               return true
           }
       }
       return false
   }
   

   Here, we don't need to know the exact types of the array elements; the promise that they each have an Int property id is enough!

   So it could allow the use of types like [DataContainer] as long as all accessed properties can be resolved statically.

2. The compiler could allow Self references if there is no ambiguity where to dispatch and/or generic implementations exist. For instance (pseudo code):

   extension DataContainer {
       static func ==<T: DataCointainer, U: DataContainer>(lhs: T, rhs:U) -> Bool {
           guard T == U else {
               return false
           }
   
           return T.==(lhs, rhs as! T)
       }
   }
   

   Such a default implementation could be used in usage contexts as the one above, i.e. if not enough type information is available to select an implementation statically.

I don't know if all problems with generic protocols can be done away with similar ideas, and if we would run into further restrictions along the road.

Answer 2

Think of it like the documentation says A protocol defines a blueprint of methods, properties, and other requirements that suit a particular task or piece of functionality.

So the protocol only says what is required to conform to it not how that is to be done. The job of 'how' is left up to whatever conforms to the protocol itself.

This means:

1) You can't use a protocol on it's own as it has no implementation itself.

2) You cannot design an API that uses protocols to hide implementation.

Basically the protocol is saying to anything that implements it 'here is what you need to do but it's up to you how to do it'.

For an API maybe you would be better off using subclassing.

(Of course there may be ways to bend a protocol to do these kind of things but then you should really think if that's the best way to do it)

Edit:

You can use self within a protocol extension but you can't use it in the way you want. I could add this to the protocol:

func doubleID() -> Int

and then create an extension like this:

extension DataContainer {
    func doubleID() -> Int {
        return self.id * 2
    }
}

So you can hide some implementation but then that is a default as whatever conforms to the protocol is free to define it's own method for doubleID.

Edit:

This will achieve what you are after though:

protocol TestProtocol: Equatable {
    var id: Int { get }
    var data: Data { get }
}

func ==<T: TestProtocol>(lhs: T, rhs: T) -> Bool {
     return lhs.id == rhs.id
}

func ==<T: TestProtocol, U: TestProtocol>(lhs: T, rhs: U) -> Bool {
    return lhs.id == rhs.id
}

func !=<T: TestProtocol, U: TestProtocol>(lhs: T, rhs: U) -> Bool {
    return lhs.id != rhs.id
}

This will provide a default equality implementation for anything that conforms to the TestProtocol however it will not stop anything overriding with its own implementation.