I like that approach a lot (and it would be nice to use separate labels vs. argument names in the case where they do have labels, too).
Enum cases with associated values are really just sugar for static methods on the enum type *anyway* with the added pattern matching abilities, so unifying the syntax seems like a positive direction to go in. On Mon, Jan 9, 2017 at 1:20 PM Tim Shadel <[email protected]> wrote: > Yeah, that's much nicer than what I just sent! :-D > > > On Jan 9, 2017, at 2:16 PM, Sean Heber <[email protected]> wrote: > > > > 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
