[swift-evolution] Consolidate Code for Each Case in Enum

[Tony Allevato]

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 <timshadel at gmail.com> 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 <
> swift-evolution at 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 at swift.org> wrote:
>
>
> > On Jan 9, 2017, at 2:28 PM, Guillaume Lessard via swift-evolution <
> swift-evolution at swift.org> wrote:
> >
> >
> >> On 9 janv. 2017, at 10:54, Tim Shadel via swift-evolution <
> swift-evolution at 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 at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170109/48757013/attachment.html>