To the topic at hand, the project I’m currently working on has 2 enums,
both with String raw values. For comparison, it has 3 classes (a Formatter
subclass, the app delegate, and one more), 4 protocols, and 47 structs.
One of the enums exists to select among the handful of struct types which
conform to one of the protocols.
> There are several things we have thought of that could potentially improve
> the situation, most notably exposing each case as an optional property.
That would be very nice.
I'd also really like to see switch-expressions (as opposed to statements).
Hmm, would a syntax like this be appropriate?
switch someValue -> [String] {
case .helloWorld: return ["Hello", "world"]
default: return []
}
That way the existing switch statement could remain as-is, and the familiar
function syntax would be used to specify the return type for switch
expressions. The “return” keyword could even be elided for single-line
cases as well, much like closures.
…oh, I just realized we’re on -users not -evolution here. Perhaps I’ll
bring this up next time switch expressions are proposed.
Nevin
On Sun, Nov 6, 2016 at 4:31 PM, Dave Abrahams via swift-users <
swift-users@swift.org> wrote:
>
> on Sun Nov 06 2016, Tino Heth <swift-users-AT-swift.org> wrote:
>
> > Enums are a fundamental part of Swift, so I guess they won't change
> > much — but I wonder if anyone shares my observations in real-life use…
> >
> > Afair, there are three different types of enums:
> > - Enums with raw values
> > - enums with associated objects
> > - Plain enums (no underlying value)
> >
> > I use the first type quite often (as a convenient way to create string
> > constants, or for serialization), but see no real value in plain enums
> > (they offer nothing over enums backed with a raw value).
> >
> > The second type is special:
> > It looks like a really cool concept, and and I started several designs
> > based on them — just to realize later that structs and classes are a
> > better fit.
> > My conclusion so far is that enums perform bad as soon as you want to
> > attach additional data or behavior; one or two computed properties are
> > ok, but those switch-statements quickly become a burden.
> > There are some options to work around this problem, but I guess I'll
> > just stay away from enums with associated objects by default (with the
> > exception of error-types — imho those can be modeled quite nicely).
> >
> > So, that's my current perception, and I'm curious if others had
> > similar experiences — or, even more interesting, completely different
> > observations and elegant solutions based on enums.
>
> I have personally always found that exuberant use of that kind of enum
> results in ergonomics and readability difficulties. There are several
> things we have thought of that could potentially improve the situation,
> most notably exposing each case as an optional property. I'd also
> really like to see switch-expressions (as opposed to statements). I'm
> not sure if that's really all we need in order to allow enums to reach
> their potential, though.
>
> --
> -Dave
>
> _______________________________________________
> swift-users mailing list
> swift-users@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users
>
_______________________________________________
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users
