I can’t speak for Tim, but I’d suggest just unifying the case syntax with functions so they become:
case foo(_ thing: Int) And if you don’t actually need to ever *use* it by name in your enum properties/functions (if you even have any), then you could leave it out and write it like it is now, but that’d become “sugar”: case foo(Int) l8r Sean > On Jan 9, 2017, at 3:11 PM, Tony Allevato <[email protected]> wrote: > > 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
