<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 12:56 PM, Nico Weber <<a href="mailto:thakis@chromium.org" class="">thakis@chromium.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Is this the only C extension you need for swift? </div></div></blockquote><div><br class=""></div><div>I believe that it’s the only non-attribute extension not covered by an existing flag.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class="">What about -fblocks?</div></div></blockquote><div><br class=""></div><div>This already has a flag, which Swift’s Clang importer can set if it’s important. I haven’t heard a ton of demand for blocks outside of Darwin clients.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="">If it's just typed enums and you don't think it'll become more over time, it probably doesn't matter much all either way. If you think you'll need more features over time, having some global toggle for this seems nice. It could default to on for -std=gnuX (if you use this, you don't mind extensions) and to off for -std=cX (if you use this, you probably want to use the language as standardized), or something like that.</div></div></div></blockquote><div><br class=""></div><div>Swift’s Clang importer can certainly use -std=gnu<whatever>, and keep fixed underlying types out of -std=c<X>.</div><div><br class=""></div><span class="Apple-tab-span" style="white-space:pre"> </span>- Doug</div><div><br class=""><blockquote type="cite" class=""><div class=""><div class="gmail_extra"><br class=""><div class="gmail_quote">On Tue, Feb 16, 2016 at 3:42 PM, Saleem Abdulrasool <span dir="ltr" class=""><<a href="mailto:compnerd@compnerd.org" target="_blank" class="">compnerd@compnerd.org</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Tuesday, February 16, 2016, Douglas Gregor via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank" class="">cfe-dev@lists.llvm.org</a>> 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=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Feb 16, 2016, at 6:46 AM, Nico Weber via cfe-dev <<a class="">cfe-dev@lists.llvm.org</a>> wrote:</div><br class=""><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 class=""><br class=""></div><div class="">We certainly can add -fswift-extensions, but it’s a level of divergence I’d like to avoid.</div></div></div></blockquote><div class=""><br class=""></div></span><div class="">Avoiding the divergence is ideal, however, this would break the meaning of -std=c11 or -std=gnu11. That was one of the other options that is available: we could vend a LLVM standard by default which would be GNU + extensions that we want to push for standardization. This would allow us to avoid the -fswift-extensions option, but retain the functionality.</div><span class=""><div class=""> </div><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=""><div class="">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 class=""><br class=""></div><div class=""><span style="white-space:pre-wrap" class=""> </span>enum {</div><div class=""><span style="white-space:pre-wrap" class=""> </span> ColorRed,</div><div class=""><span style="white-space:pre-wrap" class=""> </span> ColorGreen,</div><div class=""><span style="white-space:pre-wrap" class=""> </span> ColorBlue</div><div class=""><span style="white-space:pre-wrap" class=""> </span>};</div><div class=""><span style="white-space:pre-wrap" class=""> </span>typedef int32_t ColorType;</div><div class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class=""><span style="white-space:pre-wrap" class=""> </span>typedef enum ColorType {</div><div class=""><span style="white-space:pre-wrap" class=""> </span> ColorRed,</div><div class=""><span style="white-space:pre-wrap" class=""> </span> ColorGreen,</div><div class=""><span style="white-space:pre-wrap" class=""> </span> ColorBlue<span style="white-space:pre-wrap" class=""> </span></div><div class=""><span style="white-space:pre-wrap" class=""> </span>} ColorType;</div><div class=""><br class=""></div><div class="">Fixed underlying types address this problem with syntax that is unambiguous in C and the obvious semantics:</div><div class=""><br class=""></div><div class=""><div class=""><span style="white-space:pre-wrap" class=""> </span>typedef enum ColorType : int32_t {</div><div class=""><span style="white-space:pre-wrap" class=""> </span> ColorRed,</div><div class=""><span style="white-space:pre-wrap" class=""> </span> ColorGreen,</div><div class=""><span style="white-space:pre-wrap" class=""> </span> ColorBlue<span style="white-space:pre-wrap" class=""> </span></div><div class=""><span style="white-space:pre-wrap" class=""> </span>} ColorType;</div></div></div></div></blockquote><div class=""><br class=""></div></span><div class="">I don't think there has been any argument made that this is not a useful extension.</div><span class=""><div class=""> </div><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=""><div class=""><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></div></div></blockquote><div class=""><br class=""></div></span><div class="">As Chris mentioned, this is likely to take a long time.</div><div class=""><br class=""></div><div class="">I think that there is a middle ground where we enable the behavior by default but provide a mechanism to disable. It may be sufficient to keep both sides happy.</div><div class="HOEnZb"><div class="h5"><div class=""><br class=""></div><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=""><span style="white-space:pre-wrap" class=""> </span>- Doug</div><div class=""><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 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=""><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 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 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 class="">cfe-dev@lists.llvm.org</a><br class=""><a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" target="_blank" class="">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br class=""></div></blockquote></div><br class=""></div></blockquote><br class=""><br class="">-- <br class="">Saleem Abdulrasool<br class="">compnerd (at) compnerd (dot) org<br class="">
</div></div></blockquote></div><br class=""></div>
</div></blockquote></div><br class=""></body></html>