[swift-dev] Swift C enum Case Mapping

[Jordan Rose]

Oh, you can certainly define a macro named NS_ENUM yourself, but that doesn't really seem like the right thing to do on Linux.

As for why we can't "guess" that this is a true enum, consider the following:

enum Foo {
  A = 1,
  B = 2,
};

Is this a very small option set, or an enum that deliberately doesn't start at 0? Or just a way to define constants for some other type, rather than using "static const"? If the compiler guesses here, (a) it might guess wrong, making the type hard to use now, and (b) if the headers are updated in a newer version of the library, it might change its guess, which would break source compatibility. (This can happen anyway, e.g. the first time an annotation is added, but at least that's supposed to be changing in the right direction, and is unlikely to change again.)

Hope that clarifies the motivation here, even if it's less than satisfactory.

Jordan


> On Jan 11, 2016, at 11:22, Ryan Lovelett <swift-dev at ryan.lovelett.me> wrote:
> 
> Jordan,
>  
> Perhaps I'm not following that parenthetical comment. Are you saying that even if I could add NS_ENUM to the header it still wouldn't compile into a true Swift enum (on a non-Apple platform)?
>  
> Swift's pattern matching capability is probably a top 3 reason why I am trying to port my C application to use Swift rather than just straight C. Not being able to get this nicety out-of-the-box is just part of doing business on a bleeding edge programming language.
>  
> However this seems like something that should be able to be achieved. Looking at the fe_type enum definition, because it had no bit pattern associated with it, I would have assumed it was a true non-overlapping enum. Its probable I'm not seeing the whole landscape here so would you be able to illuminate why isn't this the default?
>  
> On Mon, Jan 11, 2016, at 01:11 PM, Jordan Rose wrote:
>> Right. This is because Swift can't tell if your enum is actually an option set, a true, non-overlapping enum, or just a set of related constants, so it picks the lowest common denominator. We currently don't have a great way to override that in headers you don't control.
>>  
>> (Heck, on non-Apple platforms we don't have a great way to do it in headers you do control; Swift is currently keying off the macro names.)
>>  
>> Jordan
>>  
>>> On Jan 10, 2016, at 13:25 , Austin Zheng via swift-dev <swift-dev at swift.org <mailto:swift-dev at swift.org>> wrote:
>>>  
>>> I spoke too soon, the cases are also defined as values of that type. So, a working version of your code:
>>>  
>>> extensionfe_type:CustomStringConvertible{
>>> publicvardescription:String{
>>> switchself{
>>> caseFE_QPSK:return"QPSK"
>>> caseFE_QAM:return"QAM"
>>> caseFE_OFDM:return"OFDM"
>>> caseFE_ATSC:return"ATSC"
>>> default:fatalError("can't be exhaustive")
>>>     }
>>>   }
>>> }
>>>  
>>> Best,
>>> Austin
>>>  
>>>> On Jan 10, 2016, at 1:22 PM, Austin Zheng <austinzheng at gmail.com <mailto:austinzheng at gmail.com>> wrote:
>>>>  
>>>> Hi Ryan,
>>>>  
>>>> Apologies, I should have been more clear. In Xcode you can alt(?)-click on a type (e.g the 'MyType' in "let a : MyType = 123") in the IDE to pop up a little window that shows you the definition, including the type and some other information. If you're on a Linux box or not using an IDE you probably don't have that option.
>>>>  
>>>> The only methods I see exposed on the Swift imported type are initializers taking a integer raw value, and a 'rawValue' property for getting back out the raw value. Hope that helps.
>>>>  
>>>> Austin
>>>>  
>>>>> On Jan 10, 2016, at 1:18 PM, Ryan Lovelett <swift-dev at ryan.lovelett.me <mailto:swift-dev at ryan.lovelett.me>> wrote:
>>>>>  
>>>>> Austin,
>>>>>  
>>>>> I guess I should say that the `typedef` is coming from aLinux kernel header <http://lxr.free-electrons.com/source/include/linux/dvb/frontend.h?v=3.2>. So I don't think I'm going to be able to add any macros to the definition.
>>>>>  
>>>>> What do you mean about alt-click? Alt click where?
>>>>>  
>>>>> On Sun, Jan 10, 2016, at 04:12 PM, Austin Zheng wrote:
>>>>>> fe_type is being imported as a struct (alt-click 'fe_type' in Swift). I think if you want it to be imported as an enum you need to use the NS_ENUM macro in the definition, which might not be possible in your case.
>>>>>>  
>>>>>> Austin
>>>>>>  
>>>>>>> On Jan 10, 2016, at 1:06 PM, Ryan Lovelett via swift-dev <swift-dev at swift.org <mailto:swift-dev at swift.org>> wrote:
>>>>>>>  
>>>>>>> typedef enum fe_type {
>>>>>>>  FE_QPSK,
>>>>>>>  FE_QAM,
>>>>>>>  FE_OFDM,
>>>>>>>  FE_ATSC
>>>>>>> } fe_type_t;
>>>>>  
>>>> 
>>>>  
>>> 
>>>  
>>> _______________________________________________
>>> swift-dev mailing list
>>> swift-dev at swift.org <mailto:swift-dev at swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-dev <https://lists.swift.org/mailman/listinfo/swift-dev>
>  

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