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

[Jordan Rose]

I don't think we have any enum case attributes, but we do allow @objc on properties:

import Foundation

class Test : NSObject {
  @objc(foo) var foo, bar : Int
}

…it looks like it ends up applying to both of them, and then erroring that you get two of the same (via the selector conflict diagnostics). We can probably make this more principled (both for cases and in general).

Jordan


> On Dec 10, 2015, at 11:30, Kevin Ballard <kevin at sb.org> wrote:
> 
> 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 <mailto: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 <mailto: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 <mailto: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/01010c53/attachment.html>