[cfe-dev] Enabling strong enum extensions under C

[Chris Lattner via cfe-dev]

> On Feb 15, 2016, at 12:24 PM, Saleem Abdulrasool via cfe-dev <cfe-dev at lists.llvm.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.

Hi Saleem,

The most conservative (and thus, probably the right answer, given that this is C) approach is to introduce a new attribute to clang to model this.  Throwing __attribute__((swift_option_set)) on the enum (or whatever) could trigger the existing Swift importer logic to handle this.

The aggressive approach would be to make several proposals to the C committee to move the C model forward, but that seems unlikely to happen.

-Chris


> 
> 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
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev