Right. This all started because Joe correctly pointed out that the motivation for is case would be a lot lower if there were an existing way to test if an enum value had a particular case, and that several of the alternative ways proposed for this in the past have been more powerful too. (In particular, they'd provide a way to get at an enum payload in expression context, which is case does not.) Past proposed alternatives I know of include
- implicitly synthesized properties, possibly opt-in (mentioned in the current
is casewrite-up) - case paths, such as the existing reflection-based implementation by Pointfree, but supported in the language
- discriminants, which are sort of between the two
In practice, I agree that we might not bother with is case if we had one of these features already. However, I do think that is case is much more tractable. We've had seven and a half years of open-source Swift and none of the proposals have been implemented for a proper review; is case is the simplest to implement; the simplest to document and teach; has the simplest compatibility story; and will remain useful even if we get one of the other features later.