[swift-evolution] [pitch] Make swift enum string available to Objc

Derrick Ho wh1pch81n at gmail.com
Tue Feb 21 17:09:07 CST 2017


True.
In my proposal I mention how NS_STRING_ENUM doesn't produce an swift enum.

So one solution is to merely "go the other way" which would produce what
Kevin N. suggested.

Is it not odd that that the objc version is so different from the swift
version?

Would it not be better to offer a somewhat similar API experience between
the two languages?

@objcstring would "promote" the swift enum to an objective-c class to make
the API experience similar.

I understand that maybe @objcstring is too niche to get its own annotation.
Instead @objc should become more powerful.

I think @objc should make an enum become a class with swift-enum like
abilities. This would allow enum functions to be bridged over to
objective-c as well.
On Tue, Feb 21, 2017 at 1:32 PM Michael Ilseman <milseman at apple.com> wrote:

> 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 <
> swift-evolution at swift.org> 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
>
> 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
> 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/20170221/b6716288/attachment.html>


More information about the swift-evolution mailing list