Hello Stephen, excuse my late response
In case there was a misunderstanding, I was talking about generating isSomeCase properties.
What I meant here is that, having a type SomeType, the compiler shouldn't generate properties whose names are based on the user specific name of the type, like isSomeTypeNice, doesSomeTypeSmoke, isSomeTypeEqualToType and so on. In our case it is an enum case, but the idea is the same. Why does it have to be considered bad code? Perhaps because it is hardcoded and not usable in the general case. I may be somewhat biased, but I am confident the majority will agree with this. All the examples of automation you listed are wonderful of course and have nothing to do with what I'm trying to point out.
I can't be formal and refer to mathematics for instance, because I understand there are various ways to model and interpret things and they are all right as long as they follow the rules, definitions and conventions of what they're built upon. object1.isEqualTo(object2) and object1 == object2 as an example. Swift is a language where arithmetic, comparison and pattern matching operations don't belong to objects, rather, they are similar to how operations over sets are defined in abstract algebra. Most of them are backed by protocols. Because of this, in my opinion, we should hold on to these semantics and keep them uniform throughout the language not to meet inconsistencies and have trouble generalizing because of different models requiring different approaches.
As for an alternate proposal, how about something similar to this?
enum Foo {
case a(Int, Bool)
case b
func match<T>(_ arg: (T) -> Foo) -> T? {
if ((T) -> Foo).self == ((Int, Bool) -> Foo).self {
...
}
...
}
}
let m = Foo.b
let o = m.match(Foo.a) // (Int, Bool)?