Ah, my apologies—the syntax highlighting in the thread was throwing off my e-mail client and I was having trouble reading it.
Associated values don't necessarily have to have names: I can write "case .foo(Int)". Since your examples use the associated value label as the name of the value inside the body, how would you handle those label-less values? On Mon, Jan 9, 2017 at 1:06 PM Tim Shadel <[email protected]> wrote: > 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 < > [email protected]> 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 < > [email protected]> wrote: > > > > On Jan 9, 2017, at 2:28 PM, Guillaume Lessard via swift-evolution < > [email protected]> wrote: > > > > > >> 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. > > 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 > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution > > >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
