A quick note addressing a misconception that you’ll want to clean up for a formal proposal:
NS_[EXTENSIBLE_]STRING_ENUMs both generate Swift structs, the difference is only in the explicitness of the rawValue initializer. To use the “other direction” analogy, you’d similarly want them to apply for rawValue-ed structs alone. The reasons are the same: only the structs are layout-compatible because enums are integers. Once you go down this route, perhaps it doesn’t make sense to annotate the struct decls themselves anymore. Maybe you just want more @objc control over bridging the types. For example, maybe you want to introduce a feature so that static members that are layout-compatible with String are bridged as global strings with the supplied name. > On Feb 20, 2017, at 4:07 PM, Derrick Ho via swift-evolution > <[email protected]> wrote: > > Swift should not forsake objective-c. At least not when it comes enum > strings. Although swift enums are suppose to be swift only, I think we > should add a new attribute to slightly relax that. I think a good attribute > would be @objcstring. > > By adding @objcstring, an objective-c exclusive class will be generated. > > @objcstring > enum Planet { > case Jupiter > } > > I have written up a proposal with more details on what it would look for > objective-c. > > https://github.com/wh1pch81n/swift-evolution/blob/swift-enum-objc/proposals/NNNN-Swift-enum-strings-ported-to-Objective-c.md > > <https://github.com/wh1pch81n/swift-evolution/blob/swift-enum-objc/proposals/NNNN-Swift-enum-strings-ported-to-Objective-c.md> > > If no one objects to this proposal I'll submit it. > > **notes: I am reviving this discussion so that I may submit this for Swift 4 > stage 2 > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
