<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Feb 16, 2016, at 6:46 AM, Nico Weber via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" class="">cfe-dev@lists.llvm.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">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></div></blockquote><div><br class=""></div><div>We certainly can add -fswift-extensions, but it’s a level of divergence I’d like to avoid.</div><div><br class=""></div><div>Regardless, enums with a fixed underlying type are an *extremely* useful extension in C, because it makes it a whole lot easier to keep an ABI stable. For example, we’ve seen a whole lot of “enumeration” types written like this:</div><div><br class=""></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>enum {</div><div><span class="Apple-tab-span" style="white-space:pre"> </span> ColorRed,</div><div><span class="Apple-tab-span" style="white-space:pre"> </span> ColorGreen,</div><div><span class="Apple-tab-span" style="white-space:pre"> </span> ColorBlue</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>};</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>typedef int32_t ColorType;</div><div><br class=""></div><div>because the authors wanted to keep ColorType 32-bit regardless of the size of “int”. Note how the typedef and enumeration type are disjoint. Doing the obvious thing creates a type that varies with the size of int:</div><div><br class=""></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>typedef enum ColorType {</div><div><span class="Apple-tab-span" style="white-space: pre;"> </span> ColorRed,</div><div><span class="Apple-tab-span" style="white-space: pre;"> </span> ColorGreen,</div><div><span class="Apple-tab-span" style="white-space: pre;"> </span> ColorBlue<span class="Apple-tab-span" style="white-space: pre;"> </span></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>} ColorType;</div><div><br class=""></div><div>Fixed underlying types address this problem with syntax that is unambiguous in C and the obvious semantics:</div><div><br class=""></div><div><div><span class="Apple-tab-span" style="white-space: pre;"> </span>typedef enum ColorType : int32_t {</div><div><span class="Apple-tab-span" style="white-space: pre;"> </span> ColorRed,</div><div><span class="Apple-tab-span" style="white-space: pre;"> </span> ColorGreen,</div><div><span class="Apple-tab-span" style="white-space: pre;"> </span> ColorBlue<span class="Apple-tab-span" style="white-space: pre;"> </span></div><div><span class="Apple-tab-span" style="white-space: pre;"> </span>} ColorType;</div><div class=""><br class=""></div><div class="">Frankly, I think standard C should adopt C++11’s enumerations with fixed underlying type, and Clang can help nudge C forward in this regard.</div><div class=""><br class=""></div></div><span class="Apple-tab-span" style="white-space:pre"> </span>- Doug</div><div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><br class=""></div><div class="">Nico</div></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Mon, Feb 15, 2016 at 11:26 PM, Jordan Rose via cfe-dev <span dir="ltr" class=""><<a href="mailto:cfe-dev@lists.llvm.org" target="_blank" class="">cfe-dev@lists.llvm.org</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" 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=""><div class="h5"><div class=""><br class=""></div><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Feb 15, 2016, at 12:24 , Saleem Abdulrasool <<a href="mailto:compnerd@compnerd.org" target="_blank" class="">compnerd@compnerd.org</a>> wrote:</div><br class=""><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="">Saleem Abdulrasool<br class="">compnerd (at) compnerd (dot) org</div>
</div>
</div></blockquote></div><br class=""></div></div></div><br class="">_______________________________________________<br class="">
cfe-dev mailing list<br class="">
<a href="mailto:cfe-dev@lists.llvm.org" class="">cfe-dev@lists.llvm.org</a><br class="">
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank" class="">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br class="">
<br class=""></blockquote></div><br class=""></div>
_______________________________________________<br class="">cfe-dev mailing list<br class=""><a href="mailto:cfe-dev@lists.llvm.org" class="">cfe-dev@lists.llvm.org</a><br class="">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev<br class=""></div></blockquote></div><br class=""></body></html>