<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Dec 10, 2015, at 2:05 PM, Evan Maloney via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">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.</div><div class=""><br class=""></div><div class="">Let me give you an example:</div><div class=""><br class=""></div><div class="">In our app, we have an enum that represents all the different <i class="">screens</i> to which the user can navigate. (A <i class="">screen</i> in our case usually means a view controller or hierarchy thereof.)</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">This allows an enum value to contain all the information needed to present any screen to the user, fully populated with content.</div><div class=""><br class=""></div><div class="">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".)</div></div></div></blockquote><div><br class=""></div><div>I might be missing something, but you can do this already. 'case .CaseWithPayload:' matches any CaseWithPayload regardless of its payload.</div><div><br class=""></div><div>-Joe</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">We've identified two possible solutions to this issue and have implemented one of them, but it is still sub-optimal:</div><div class=""><br class=""></div><div class="">• 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.</div><div class=""><br class=""></div><div class="">• 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.</div><div class=""><br class=""></div><div class="">---</div><div class=""><br class=""></div><div class="">When an enum case takes one or more associated values, it acts more like a <i class="">type</i> than a <i class="">value</i> 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.</div><div class=""><br class=""></div><div class="">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:</div><div class=""><br class=""></div><div class="">enum Foo<br class="">{<br class=""> case Bar(String)<br class=""> case Baz(Int, Int)<br class=""><br class=""> // generated by the compiler; returns the parallel FooType<br class=""> // with cases that don't have associated values<br class=""> var enumType: FooType<br class="">}<br class=""><br class="">// generated by the compiler when an enum</div><div class="">// has at least one associated value<br class="">enum FooType<br class="">{<br class=""> case Bar<br class=""> case Baz<br class="">}<br class=""></div><div class=""><br class=""></div><div class="">This would make it possible to be able to refer to cases in the abstract.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">E.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><blockquote type="cite" class="">On Dec 10, 2015, at 8:24 AM, plx via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class="">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:<br class=""><br class="">@synthesize_case_enum<br class="">enum Example {<br class=""><br class=""> case Foo(X)<br class=""> case Bar<br class=""> case Baz(Y)<br class=""><br class="">}<br class=""><br class="">…which would then by default expand to something like this:<br class=""><br class="">enum ExampleCase : Int {<br class=""><br class=""> case Foo<br class=""> case Bar<br class=""> case Baz<br class=""><br class="">}<br class=""><br class="">extension Example {<br class=""><br class=""> var enumerationCase: ExampleCase {<br class=""> get {<br class=""> switch self {<br class=""> case .Foo(_): return .Foo<br class=""> case .Bar(_): return .Bar<br class=""> case .Baz(_): return .Baz<br class=""> }<br class=""> }<br class=""> } <br class=""><br class="">}<br class=""><br class=""></blockquote></div>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=RoDF4MveSEMYBIqIJA6ub1g8cOZ-2BVYvqV-2FqygPhjPn-2BczUm64ISF8-2FlK1enkxDQz6q7GSWrsdAoKGnpWF-2FlIt40kwzHOWVN2dUe3K0WeiyeTONaz9-2Bbf4V4mgbH-2F4B8bTxNXQ7RCAGapITaK9Oq7ncuR45NrYV-2BH-2BXBIitf0eLrLSXCmXz-2BctgN-2Bb-2FjvsLh26L1VFDnWdPyXHESsT5yApy6q8JffaNKSlUPNfzNQ2To-3D" alt="" width="1" height="1" border="0" style="height:1px !important;width:1px !important;border-width:0 !important;margin-top:0 !important;margin-bottom:0 !important;margin-right:0 !important;margin-left:0 !important;padding-top:0 !important;padding-bottom:0 !important;padding-right:0 !important;padding-left:0 !important;" class="">
</div>
_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></body></html>