I understand this very well. However this is not always what you want. This design has a number of consequences. It requires a standalone function for each pieces of logic that would otherwise be contained in a switch statement, including a common result. It also requires that this function be visible on all concrete conforming types. This approach does not work well for single-use logic that should not have such a prominent position and visibility.
Sealed protocols with exhaustive switching can be used in a way that is more analogous to enums than to classes. This enables use cases where enums just don't work because cases are not types and an enum cannot be used as a constraint on types. In these use cases the protocol is quite similar to an enum where each case has an associated value. Switching over a protocol designed in this way would not be something "dirty" and to be avoided, but rather a central aspect of its design. Part of the semantics of the protocol is the specific set of types that conform, just as part of the semantics of an enum are defined by its cases.
These enum-like protocols would be a Swifty protocol-oriented, (sometimes) value-semantic version of the object-oriented "case classes" we see in other languages like Kotlin and Scala. They are not redundant with enums but rather complementary. The discussion of protocols vs enums earlier in the thread demonstrates how they have much different properties and are therefore applicable in different scenarios. There is a hole in the design space available to us right now and exhaustive switch over
sealed protocols would fill it very nicely.
If we could have exhaustive switching without any special linguistic construct that would be fine with me. However, many comments in this thread make it sound like it is unlikely to be feasible and perhaps even unlikely to be attempted to implement exhaustive switch if the compiler needs to scan an entire module to find the full set of conformances. So the reason it would be limited to this one flavor of protocol is pretty good: without this flavor of protocol we wouldn't be able to have the feature at all.
If this is true then
sealed protocols are likely to be the one chance we have to realize exhaustive switch over protocols. This is an important type system feature that would open up a new range of design choices that are simply not available without it.
FWIW, if we design
sealed protocols in this way there is no reason we couldn't also have
sealed classes which would also support exhaustive switch. I think the motivation for this in the OO design space is weaker, especially if we have
sealed protocols but there would be an argument for consistency and precedent in the Scala and Kotlin "case classes".
I admit that it would be slightly annoying when the use case is something other than the enum-like protocols I described above. But I also think opening up the design space of enum-like protocols is much more important. Keep in mind that it is only the conformance declaration that would need to be in the same file as the protocol. The implementation of all requirements could live in other files. This would be slightly unfortunate as we usually like to declare the conformance together with the implementation of the requirements, but we don't have to. And again, I think opening up the design space of enum-like protocols is more important.
Sure, but the earlier parts of the thread somewhat strongly imply that such a thing is not likely to ever exist.
This advice makes sense given the current capabilities of protocols. It wouldn't always make sense if the language supported switching over
sealed protocols, because in that language we would be able to design enum-like protocols.
The earlier parts of this thread make it sound like this kind of exhaustive checking of visible conformances is problematic to implement and therefore unlikely to be implemented.