There are examples of associated values in the proposed syntax. Which parts should I provide more detail on?
> On Jan 9, 2017, at 1:43 PM, Tony Allevato via swift-evolution > <swift-evolution@swift.org> wrote: > > 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@swift.org <mailto:swift-evolution@swift.org>> wrote: > > > On Jan 9, 2017, at 2:28 PM, Guillaume Lessard via swift-evolution > > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: > > > > > >> On 9 janv. 2017, at 10:54, Tim Shadel via swift-evolution > >> <swift-evolution@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@swift.org> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution> > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
