I got to this weird compiler limitation in Swift 3.1, tested in a playground. Any solution?
Seems like a compiler bug, suggestions? Thanks :)
Asked
Active
Viewed 305 times
2
-
3Yes, [protocols do not conform to themselves](http://stackoverflow.com/q/33112559/2976878) – you cannot use `Protocol1` as a type that conforms to `Protocol1`. This isn't a bug, it's by design. – Hamish Apr 13 '17 at 17:06
-
Thanks for the answer. Makes non sense right? This is such a nonesense limitation.. – acecilia Apr 13 '17 at 17:10
-
It does make sense. Consider if you had a `static` protocol requirement on `Protocol1` – if I had a `func foo
(_: T.Type) {}`, I can access static protocol requirements on `T`. You cannot access static requirements on a protocol type, only on concrete types – therefore allowing protocols to conform to themselves is unsound. I do however agree that the workaround (type erasers) is quite mundane – hopefully in a future version of the language, Swift will support *some* language feature to alleviate this burden. – Hamish Apr 13 '17 at 17:23 -
@Hamish I do not really see the point in what you said about a static protocol requirement, I tested your proposal and the result is here: http://imgur.com/iFbZA0m – acecilia Apr 14 '17 at 01:10
-
I was talking about calling the static requirements on `T`, not `param` (which is an existential metatype in your example, so works fine). To be fair, it wasn't the best example – I have illustrated a (hopefully) better one in [my answer to the linked Q&A here](http://stackoverflow.com/a/43408193/2976878) :) – Hamish Apr 14 '17 at 08:52
-
Oh wow, totally forgot that I've already answered basically this exact question [here](http://stackoverflow.com/q/37360114/2976878) – will go ahead and close as a dupe of both :) – Hamish Apr 14 '17 at 21:22
