[swift-evolution] Consolidate Code for Each Case in Enum

Tony Allevato tony.allevato at gmail.com
Mon Jan 9 14:43:51 CST 2017

While I do like the consolidated syntax more than most of the alternatives
I've seen to address this problem, any proposed solution also needs to
address how it would work with cases that have associated values. That
complicates the syntax somewhat.

On Mon, Jan 9, 2017 at 12:37 PM Sean Heber via swift-evolution <
swift-evolution at swift.org> wrote:

> > On Jan 9, 2017, at 2:28 PM, Guillaume Lessard via swift-evolution <
> swift-evolution at swift.org> wrote:
> >
> >
> >> On 9 janv. 2017, at 10:54, Tim Shadel via swift-evolution <
> swift-evolution at swift.org> 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.
> I’m not sure how to argue this, but I feel pretty strongly that something
> more like this proposed organization *is* actually better. That said, I do
> not think this conflicts with the current design of enums, however, so this
> is likely purely additive. The current design makes some situations almost
> comically verbose and disorganized, IMO, but it *is* right for other
> situations. We may want to have both.
> l8r
> Sean
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170109/79aff488/attachment.html>

More information about the swift-evolution mailing list