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