[cfe-dev] Enabling strong enum extensions under C

[Jordan Rose via cfe-dev]

Hi, Saleem. I think you've conflated two features here:

- ObjC's implementation of C++11's "enums with fixed underlying types" feature.
- An as-of-yet-undesigned annotation (attribute?) on enums that describes if they are really exclusive enums (like CF_ENUM) or bitsets (CF_OPTIONS) or just random constants.

I think these should be discussed separately, and I think you're more interested in the former right now. Is that correct?

If so, this certainly seems reasonable to me. Like many other things added to the language, we can treat this as a feature of Objective-C and C++ >= 11, and an extension in C and C++ < 11. (This is the technical difference between __has_feature and __has_extension.) I think the Objective-C implementation of this is close to what would eventually go into the C standard, so treating it as a general language extension makes sense to me.

Jordan


> On Feb 15, 2016, at 12:24 , Saleem Abdulrasool <compnerd at compnerd.org> wrote:
> 
> Hi,
> 
> Swift has generally been well-received, and there is active development
> occurring to support it well on other targets, including ports to Android and
> FreeBSD.  As part of this work, it has become apparent that certain (objc)
> extensions would be extremely useful to have available when working with swift.
> 
> One such feature in particular is CF_ENUM/CF_OPTIONS support.  This is currently
> only enabled under Objective-C compilation.  This extension provides strong
> enums similar to C++11's enum class.  In order to improve Swift's
> interoperability, it would be useful to enable this in C as well.
> 
> To explain the utility more concretely, enabling this extension allows for
> cleaner cross-platform code in Swift.  Having differences in the C variant means
> that the code needs to be conditionalised via '#if' checks, making it difficult
> to follow.  Most swift code is written against a C variant which enables strong
> enumerations by default, and this results in a difference in the language
> constructs based on the environment.  Most documentation and example code are
> written assuming this as well and it can be very difficult to diagnose why code
> works in one environment but not the other.  This disparity makes interfacing
> with libraries a challenging endeavour for developers.
> 
> The question is what is the best option for enabling this extension on platforms
> where we have non-clang compatibility involved (e.g. Linux).  Should we just be
> aggressive and introduce additional compiler specific extensions without
> considerations for `-std`, vend a custom standard, or introduce a feature flag
> to control these additional extensions that are useful for Swift.
> 
> There are pros and cons to each option, and this email is intended to open a
> dialogue around which option would be the best long term for clang and the
> language in general.
> 
> Thanks!
> 
> -- 
> Saleem Abdulrasool
> compnerd (at) compnerd (dot) org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20160215/6184a226/attachment.html>