<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=""><div class=""><br class=""></div><br class=""><div><blockquote type="cite" class=""><div class="">On Dec 10, 2015, at 4:05 PM, Evan Maloney <<a href="mailto:emaloney@gilt.com" class="">emaloney@gilt.com</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 class=""><br class=""></div><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></div></blockquote><div><br class=""></div>^ this is what I have been doing by hand when needed (mainly to support serialization); as you say, the compiler doesn’t do anything enforce the two "parallel enums" stay in sync with each other.<br class=""><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="">• 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></div></blockquote><div><br class=""></div>^ in your use case I’d probably do something analogous, but even this isn’t necessarily always workable (sometimes multiple cases have the same type of associated value, and aside from *being* a runtime check you risk having the wrong value even if the types match; wouldn’t usually be a risk for view models, but you might have e.g. different “types” of image URLs that need different HTTP headers added to their requests...).</div><div><br class=""></div><div>But yes, this is exactly the situation I’m driving at. </div><div><br class=""></div><div>If compiler support to synthesize these enums is added I’d prefer it be opt-in, if only to have a natural place in the syntax to customize some of the details (e.g. maybe UInt vs Int, maybe you want @objc on it, and for serialization support starting the “parallel enum” from 1 instead of 0 smooths over a mild annoyance with the `NSCoder` API).</div><div><br class=""></div><div>But these are definitely the kinds of things I had in mind.</div><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=""><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></div></div></blockquote></div><br class=""></body></html>