[swift-evolution] Proposal: Allow @objc(name) on enum declarations

[Kevin Ballard]

Do we have any attributes that are valid on enum cases today? If so, how
do they handle this scenario?

I'm inclined to agree with you that it should be an error. It's
reasonable to assume that an attribute on the declaration applies to all
cases in the declaration, which is fine for most attributes, it just
doesn't work for @objc(name) because it produces a name collision.

I suspect the simplest approach here is to just figure out what the
error message will be if you say

@objc(Foo) case Foo @objc(Foo) case Bar

and use the same error if you say

@objc(Foo) case Foo, Bar

-Kevin Ballard

On Thu, Dec 10, 2015, at 07:22 AM, Harlan Haskins wrote:
> An error seems reasonable here.
>
> Error: Ambiguous Objective-C case name for ‘.Two’.
>
> And then the Fix-It is just to put the second case on a new line and
> provide the @objc(<#name#>) completion.
>
>> On Dec 10, 2015, at 1:56 AM, Kevin Ballard via swift-evolution <swift-
>> evolution at swift.org> wrote:
>>
>> Does it make sense to put @objc(name) on enum cases? Such as
>>
>> @objc enum Foo: Int {    @objc(kFooOne) case One    @objc(kFooTwo)
>> case Two }
>>
>> The only real problem here is what do we do if you say
>>
>> @objc(kFooOne) case One, Two
>>
>> Either we just apply it to the One variant and ignore the Two
>> variant, possibly with a warning, or we emit an error.
>>
>> -Kevin
>>
>> On Wed, Dec 9, 2015, at 06:01 PM, Jordan Rose wrote:
>>>
>>>> On Dec 9, 2015, at 15:18, Kevin Ballard via swift-evolution <swift-
>>>> evolution at swift.org> wrote:
>>>>
>>>> Swift allows for placing @objc on an enum that has an Int raw type
>>>> in order to expose it to Obj-C. But it doesn't currently let you
>>>> rename the enum when exposing it to Obj-C. This is particularly
>>>> problematic when exposing a Swift enum that's nested in a
>>>> struct/class, as the nesting resolves ambiguity in Swift but is not
>>>> present in Obj-C.
>>>>
>>>> Example:
>>>>
>>>> import Foundation
>>>>
>>>> class Foo: NSObject {   @objc enum Bar: Int {       case One,
>>>> Two   } }
>>>>
>>>> This generates the following:
>>>>
>>>> SWIFT_CLASS("_TtC7unnamed3Foo") @interface Foo : NSObject
>>>> - (nonnull instancetype)init OBJC_DESIGNATED_INITIALIZER; @end
>>>>
>>>> typedef SWIFT_ENUM(NSInteger, Bar) { BarOne = 0, BarTwo = 1, };
>>>>
>>>> I'd like to resolve this by saying @objc(FooBar) but that emits an
>>>> error.
>>>>
>>>> I'm also going to submit a separate proposal saying we should
>>>> change the default naming here so the enum is named FooBar, but
>>>> these two proposals go hand-in-hand (there are cases where you
>>>> might want to rename a root-level enum, to add a prefix for
>>>> disambiguation in Obj-C, or you may want to selectively opt out of
>>>> the proposed renaming rules by forcing your nested enum to use just
>>>> its name in Obj-C).
>>>
>>> +1 to being able to rename @objc enums. I'm a little surprised we
>>> even allow exposing nested types to Objective-C, and am not at all
>>> sure the printer is set up to handle that correctly, but the
>>> renaming is independently useful.
>>>
>>> Jordan
>> _______________________________________________
>> 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/fe7e5211/attachment.html>