<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Hi, Saleem. I think you've conflated two features here:</div><div class=""><br class=""></div><div class="">- ObjC's implementation of C++11's "enums with fixed underlying types" feature.</div><div class="">- 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.</div><div class=""><br class=""></div><div class="">I think these should be discussed separately, and I <i class="">think</i> you're more interested in the former right now. Is that correct?</div><div class=""><br class=""></div><div class="">If so, this certainly seems reasonable to me. Like many other things added to the language, we can treat this as a <i class="">feature</i> of Objective-C and C++ >= 11, and an <i class="">extension</i> 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.</div><div class=""><br class=""></div><div class="">Jordan</div><div class=""><br class=""></div><br class=""><div><blockquote type="cite" class=""><div class="">On Feb 15, 2016, at 12:24 , Saleem Abdulrasool <<a href="mailto:compnerd@compnerd.org" class="">compnerd@compnerd.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Hi,<br class=""><div class=""><br class=""></div><div class="">Swift has generally been well-received, and there is active development</div><div class="">occurring to support it well on other targets, including ports to Android and</div><div class="">FreeBSD.  As part of this work, it has become apparent that certain (objc)</div><div class="">extensions would be extremely useful to have available when working with swift.</div><div class=""><br class=""></div><div class="">One such feature in particular is CF_ENUM/CF_OPTIONS support.  This is currently</div><div class="">only enabled under Objective-C compilation.  This extension provides strong</div><div class="">enums similar to C++11's enum class.  In order to improve Swift's</div><div class="">interoperability, it would be useful to enable this in C as well.</div><div class=""><br class=""></div><div class="">To explain the utility more concretely, enabling this extension allows for</div><div class="">cleaner cross-platform code in Swift.  Having differences in the C variant means</div><div class="">that the code needs to be conditionalised via '#if' checks, making it difficult</div><div class="">to follow.  Most swift code is written against a C variant which enables strong</div><div class="">enumerations by default, and this results in a difference in the language</div><div class="">constructs based on the environment.  Most documentation and example code are</div><div class="">written assuming this as well and it can be very difficult to diagnose why code</div><div class="">works in one environment but not the other.  This disparity makes interfacing</div><div class="">with libraries a challenging endeavour for developers.</div><div class=""><br class=""></div><div class="">The question is what is the best option for enabling this extension on platforms</div><div class="">where we have non-clang compatibility involved (e.g. Linux).  Should we just be</div><div class="">aggressive and introduce additional compiler specific extensions without</div><div class="">considerations for `-std`, vend a custom standard, or introduce a feature flag</div><div class="">to control these additional extensions that are useful for Swift.</div><div class=""><br class=""></div><div class="">There are pros and cons to each option, and this email is intended to open a</div><div class="">dialogue around which option would be the best long term for clang and the</div><div class="">language in general.</div><div class=""><br class=""></div><div class="">Thanks!</div><div class=""><br class=""></div><div class="">-- <br class=""></div><div class="gmail_signature">Saleem Abdulrasool<br class="">compnerd (at) compnerd (dot) org</div>
</div>
</div></blockquote></div><br class=""></body></html>