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

[Douglas Gregor]

Sent from my iPhone

> On Dec 14, 2015, at 10:59 PM, Kevin Ballard <kevin at sb.org> wrote:
> 
>> On Mon, Dec 14, 2015, at 09:34 PM, Douglas Gregor wrote:
>>  
>>> On Dec 14, 2015, at 6:52 PM, Kevin Ballard <kevin at sb.org> wrote:
>>>  
>>> (I haven't touched case prefix stripping; presumably it's trying to strip the Swift name instead of the ObjC name)
>>  
>> Probably. It’s not actually clear which prefix it should try stripping with.
>  
> It seems to me that it should strip the ObjC name, as the enum constants will presumably be named after the ObjC enum name. I already went ahead and implemented this earlier today and it works (I added an option to ClangImporter::Implementation::importFullName called ImportNameFlags::IgnoreSwiftNameAttr).

Note that you could grab the name directly from the Clang declaration with a small amount of effort, so it doesn't get translated at all. 

>  
>>> But if I actually try and reference the type Bar, it tells me it's an undeclared type!
>>  
>> Yeah, there is some known brokenness here: the swift_name attribute doesn’t actually work on global declarations, because the Clang importer currently makes assumptions about the mapping from Swift names to Objective-C names. That’s exactly why I’m introducing the Swift name lookup tables into the Clang importer now, because they make it possible for arbitrary renaming of Objective-C entities to actually work in Swift.
>  
> Ah ok. I assumed that because there was code in here to look for the attribute that it was expected to work.

I'm in the middle of implementing generalized swift_name support. importFullName is about a week old :)
>  
>> Your macro is swift_name’ing the enum but not the typedef, which is why there are entries for both Bar -> FooBar and FooBar -> FooBar. The duplication in the FooBar result is interesting, though: perhaps it’s related to the fact that the enum is first declared without the swift_name attribute?
>  
> Should I be swift_name'ing the typedef too?

IMO, yes. We want both the enum and typedef to have the new name. 

>  
> As for the duplication, that actually matches the output from the IDE/dump_swift_lookup_tables.swift file. Given the following Obj-C declaration:
>  
> // Renaming enumerations.
> SWIFT_ENUM(unsigned char, SNColorChoice) {
>   SNColorRed SWIFT_NAME(Rouge),
>   SNColorGreen,
>   SNColorBlue
> };
>  
> The test explicitly looks for
>  
> // CHECK-NEXT:   SNColorChoice:
> // CHECK-NEXT:     TU: SNColorChoice, SNColorChoice

Sure. One is the enum, one is the typedef. 

>  
> The thing that was weird in my case was that it was using the name FooBar instead of Bar.

I expected one FooBar for the typedef. It's the other that surprised me. 
>  
>> It’s fine to submit a PR for this that tests what works (e.g., use FileCheck to verify that the Swift API dumps for the imported enum have the right names) and also have some tests that verify the bad behavior (“cannot find Bar”) with a FIXME to say that the test should succeed. That way, you can get your change in and move the needle forward a little, and when we start turning on the Swift name lookup tables, these tests will help us see that more things are working.
>  
> Ok, I'll figure out what tests I can write now for this and I'll submit the PR soon (probably tomorrow evening).

Okay!

  - Doug

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20151214/d06f42f6/attachment.html>