I think this is a problem worth solving. It's unfortunate that case name overloads complicate this so much. I'm assuming it's too late to remove support for that, but I think we'd end up with a much cleaner model if we could.
I'd prefer to take the property synthesis approach, which I think is very clean and straightforward. Due to case overloads though, doing it properly would require supporting property overloads. Which I think is reasonable given that parameterless functions can be overloaded, but it complicates getting this proposal through. I still think it's the correct approach, though.
Another option that I think would be elegant if not for case overloads is having a synthesized, nested Case
enum for payload-bearing enums, which has also been discussed here before. Like this:
enum Foo {
case bar(Int)
case baz(String)
// Synthesized:
enum Case {
case bar, baz
}
var case: Case { ... }
}
Then you can do things like foo.case == .bar
, foo.payload(for: .bar)
, etc. It's also useful on its own -- it's not uncommon in my experience to want to refer to enum cases in general without their payloads. But this seems to be a no-go given that there's no reasonable way to synthesize the Case
enum when there are case name overloads.