[charlesism]

I don't know how Haskell does it, but, at present, Swift enums with payloads have caveats that simple Swift enums don't:

- they use this verbose syntax to access payloads "if case let .foo(bar) = baz { /* do something with bar */ }" The alternative being to do everything in a switch statement, and possibly create a local variable thanks to scope

- their payloads are not convertible to tuples, despite their cosmetic similarity

- they do not allow default values, despite their cosmetic similarity to swift function parameters (which do support default values)

- they aren't automatically Hashable and Equatable

- they aren't automatically included in the Enum's array of ".allCases"

The great thing about Swift is that all of these issues can be worked around using extensions. Unfortunately (the way I do things, anyways) that means a lot of the time in Swift, the Enum itself is maybe 5 lines long, while my extensions to work around the above limitations go on and on for another 30+ lines.

[__sdegutis]

That sounds like a failure of a language to me. When you have to create long ugly hacks to work around the language's limitations, then it's not working for you but against you. I've been writing in Objective-C ever since abandoning Swift 2 and so far I've only really ever heard people say they're having this or that major difficulty with Swift, so it makes me feel like it was the right thing to do to avoid getting heavily invested in Swift.

[uryga]

Do you have any ideas for a more ergonomic way of accessing the fields? I'm asking because I'm working on an enum library for Python (shameless plug: [0]) and looking for ways to improve it, though of course it has different constraints.

[0] https://github.com/lubieowoce/sumtype