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

[Douglas Gregor]

> On Dec 11, 2015, at 10:33 PM, Kevin Ballard <kevin at sb.org> wrote:
> 
> On Fri, Dec 11, 2015, at 10:05 PM, Douglas Gregor wrote:
>>  
>>> On Dec 11, 2015, at 9:40 PM, Kevin Ballard <kevin at sb.org <mailto:kevin at sb.org>> wrote:
>>>  
>>> Will do. My worry with using swift_name is that, at least in the clang that ships with Xcode 7.2, you can't actually put the swift_name attribute on an enum. I assume that will change with SE-0005, but I also assume this hasn't been implemented yet. And even when it is implemented, emitting it will be a backwards-compatibility hazard if the generated header needs to work with older clangs. Is there any way to suppress the error?
>>  
>> Hrm, that’s a good point. The generalized swift_name support is implemented in upstream Clang, but you’re right that Xcode 7.2 won’t be able to parse it. We can add a “__has_feature” entry for generalized swift_name in Clang and wrap this particular use of swift_name in
>>  
>> #if __has_feature(generalized_swift_name)
>> // ...
>> #endif
>  
> That works for me. Can I assume this will get added by someone who's familiar with clang, or should I try and figure out how to do this myself and submit a patch?

I went ahead and did this in

	https://github.com/apple/swift-clang/commit/f66c5bb67b9a1016b51d2eff0f497d4528dacc0a <https://github.com/apple/swift-clang/commit/f66c5bb67b9a1016b51d2eff0f497d4528dacc0a>

and it’s cherry-picks.

	- Doug


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151212/df8d23a6/attachment.html>