<div dir="ltr">Personally, I'd like if -std=c11 would give you C11 without extensions. I know that's currently not the case and that GNU and clang extensions are enabled by default, but I really like the model we're using in clang-cl: -std=c++11 gives you C++11-per-spec, and if you pass -fms-extensions and -fms-compatiblity, you get the Microsoft extensions. And if you want, -Wmicrosoft will warn you every time you use one that isn't in a system header. I wish that we had a similar setup for GNU extensions -- doing this has been discussed on this list a few times; maybe it'll happen one day. Maybe the Swift extension setup could be similar? -fswift-extensions to opt in (your third proposal), and some warning group to warn about each use of such an extension.<div><br></div><div>Nico</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Feb 15, 2016 at 11:26 PM, Jordan Rose via cfe-dev <span dir="ltr"><<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>Hi, Saleem. I think you've conflated two features here:</div><div><br></div><div>- ObjC's implementation of C++11's "enums with fixed underlying types" feature.</div><div>- 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><br></div><div>I think these should be discussed separately, and I <i>think</i> you're more interested in the former right now. Is that correct?</div><div><br></div><div>If so, this certainly seems reasonable to me. Like many other things added to the language, we can treat this as a <i>feature</i> of Objective-C and C++ >= 11, and an <i>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><br></div><div>Jordan</div><div><div class="h5"><div><br></div><br><div><blockquote type="cite"><div>On Feb 15, 2016, at 12:24 , Saleem Abdulrasool <<a href="mailto:compnerd@compnerd.org" target="_blank">compnerd@compnerd.org</a>> wrote:</div><br><div><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>Saleem Abdulrasool<br>compnerd (at) compnerd (dot) org</div>
</div>
</div></blockquote></div><br></div></div></div><br>_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
<br></blockquote></div><br></div>