[cfe-dev] Enabling strong enum extensions under C

[Saleem Abdulrasool via cfe-dev]

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/97ddc45f/attachment.html>