> On 9 janv. 2017, at 10:54, Tim Shadel via swift-evolution > <[email protected]> wrote: > > Enums get large, and they get complicated because the code for each case gets > sliced up and scattered across many functions. It becomes a "one of these > things is not like the other" situation because writing functions inside > enums is unlike writing functions in any other part of Swift code.
The problem I see with this is that enums and their functions inherently multiply each other. If I have 3 cases and 3 functions or properties, there are 9 implementation details, no matter how they're organized. There can be 3 functions/properties, each with a 3-case switch, or there can be 3 enum cases each with 3 strange, partial functions/properties. I can see why someone might prefer one over the other, but is either way truly better? The current way this works at least has the merit of not requiring a special dialect for enums. Cheers, Guillaume Lessard _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
