[swift-evolution] Request: Ability to refer to an enum case in abstract (without its associated value)
J. Cheyo Jimenez
cheyo at masters3d.com
Thu Dec 10 19:19:58 CST 2015
//Swift version 2.2-dev
enum case 'CaseWithPayload' not found
On Thu, Dec 10, 2015 at 3:31 PM, Joe Groff via swift-evolution <
swift-evolution at swift.org> wrote:
>
> On Dec 10, 2015, at 2:05 PM, Evan Maloney via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> I'm not sure if this is what you're driving at, but I've found a use-case
> for the ability to refer to an enum case generically without reference to
> any of its associated values.
>
> Let me give you an example:
>
> In our app, we have an enum that represents all the different *screens* to
> which the user can navigate. (A *screen* in our case usually means a view
> controller or hierarchy thereof.)
>
> Because each screen might require specific view model object(s) to render
> their content, some of our enum cases have associated values to store the
> required view model objects.
>
> This allows an enum value to contain all the information needed to present
> any screen to the user, fully populated with content.
>
> However, in a few instances I've found it would be helpful to be able to
> refer to a screen in the abstract and be able to 'switch' against it
> without any associated values. (This would allow me to be able to refer to,
> say, "the User Account screen" in the abstract, whereas now I can only
> refer to "the User Account screen displaying details for this particular
> user".)
>
>
> I might be missing something, but you can do this already. 'case
> .CaseWithPayload:' matches any CaseWithPayload regardless of its payload.
>
> -Joe
>
> We've identified two possible solutions to this issue and have implemented
> one of them, but it is still sub-optimal:
>
> • One option involves maintaining a parallel enum with the same case names
> but without any associated values. These parallel structures need to be
> manually maintained, which is something the compiler cannot enforce.
>
> • Another option involves removing the associated values from the enum and
> passing around objects to contain the necessary view model objects. At
> various points, we assert that the view model container object is of the
> expected type for the enum case, but again, that now moves to runtime an
> error that otherwise would've been caught by the compiler.
>
> ---
>
> When an enum case takes one or more associated values, it acts more like a
> *type* than a *value* because it specifies a format for storing
> information without specifying the exact informations stored. We're able to
> refer to other types as such in Swift, but not in this case.
>
> I think it would be helpful if any enum with at least one case had a
> parallel representation containing the same cases but without associated
> values. It might look like:
>
> enum Foo
> {
> case Bar(String)
> case Baz(Int, Int)
>
> // generated by the compiler; returns the parallel FooType
> // with cases that don't have associated values
> var enumType: FooType
> }
>
> // generated by the compiler when an enum
> // has at least one associated value
> enum FooType
> {
> case Bar
> case Baz
> }
>
> This would make it possible to be able to refer to cases in the abstract.
>
> Perhaps there's a totally different solution to this class of problem, but
> that's what I came up with. Would love to hear your thoughts.
>
> E.
>
>
>
> On Dec 10, 2015, at 8:24 AM, plx via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> FWIW, as long as we’re asking for some compiler assistance generating
> useful enumeration-related boilerplate, I’d like to request that something
> along these lines be possible in some version of Swift:
>
> @synthesize_case_enum
> enum Example {
>
> case Foo(X)
> case Bar
> case Baz(Y)
>
> }
>
> …which would then by default expand to something like this:
>
> enum ExampleCase : Int {
>
> case Foo
> case Bar
> case Baz
>
> }
>
> extension Example {
>
> var enumerationCase: ExampleCase {
> get {
> switch self {
> case .Foo(_): return .Foo
> case .Bar(_): return .Bar
> case .Baz(_): return .Baz
> }
> }
> }
>
> }
>
> _______________________________________________
> 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/20151210/68d4a274/attachment.html>
More information about the swift-evolution
mailing list