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
