I definitely take @1oo7's point that the error message and underlying failure here are quite confusing—a quick search of StackOverflow turns up countless results for the same issue. It's also true that in the 'easy' cases, such as FooProtocol, it's conceptually sound for a protocol to conform to itself. After all, the static type FooProtocol obviously trivially satisfies the requirements of FooProtocol.
But as soon as the protocols start getting more complex (such as in the ways @xwu mentioned), there's a lot of tricky questions to be answered, and the language currently doesn't have the expressive power to cover those cases. Adding a one-off rule of "'simple' protocols may self-conform" without the additional features needed to generalize the rule may leave the language in a worse resting place than we have currently (or, maybe not! I'm unsure whether there's been extensive discussion around allowing self-conformance for a very limited subset of protocols).
To your point about being able to access static or init requirements from an instance, @1oo7, it's worth pointing out that Swift's generics model doesn't require that a generic parameter be attached to an instance at all. Consider:
protocol FooProtocol {
var bar: Int { get set }
init(bar: Int)
static func perform()
}
struct FooCreator<T: FooProtocol> {
func giveMeAFoo() -> T { T.init(bar: 0) }
}
Right now, there's simply no way for a FooCreator<FooProtocol> to function. Yes, if we had some foo: FooProtocol we could do type(of: foo).init(bar: 0), but that's not going to be possible generally since generic functions and types can be parameterized by just the type.