On Tuesday, February 16, 2016, Douglas Gregor via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>> 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"><br><div><blockquote type="cite"><div>On Feb 16, 2016, at 6:46 AM, Nico Weber via cfe-dev <<a href="javascript:_e(%7B%7D,'cvml','cfe-dev@lists.llvm.org');" target="_blank">cfe-dev@lists.llvm.org</a>> wrote:</div><br><div><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></div></blockquote><div><br></div><div>We certainly can add -fswift-extensions, but it’s a level of divergence I’d like to avoid.</div></div></div></blockquote><div><br></div><div>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><div> </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"><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></div><div><span style="white-space:pre-wrap"> </span>enum {</div><div><span style="white-space:pre-wrap"> </span> ColorRed,</div><div><span style="white-space:pre-wrap"> </span> ColorGreen,</div><div><span style="white-space:pre-wrap"> </span> ColorBlue</div><div><span style="white-space:pre-wrap"> </span>};</div><div><span style="white-space:pre-wrap"> </span>typedef int32_t ColorType;</div><div><br></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></div><div><span style="white-space:pre-wrap"> </span>typedef enum ColorType {</div><div><span style="white-space:pre-wrap"> </span> ColorRed,</div><div><span style="white-space:pre-wrap"> </span> ColorGreen,</div><div><span style="white-space:pre-wrap"> </span> ColorBlue<span style="white-space:pre-wrap"> </span></div><div><span style="white-space:pre-wrap"> </span>} ColorType;</div><div><br></div><div>Fixed underlying types address this problem with syntax that is unambiguous in C and the obvious semantics:</div><div><br></div><div><div><span style="white-space:pre-wrap"> </span>typedef enum ColorType : int32_t {</div><div><span style="white-space:pre-wrap"> </span> ColorRed,</div><div><span style="white-space:pre-wrap"> </span> ColorGreen,</div><div><span style="white-space:pre-wrap"> </span> ColorBlue<span style="white-space:pre-wrap"> </span></div><div><span style="white-space:pre-wrap"> </span>} ColorType;</div></div></div></div></blockquote><div><br></div><div>I don't think there has been any argument made that this is not a useful extension.</div><div> </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"><div><div><div>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><br></div><div>As Chris mentioned, this is likely to take a long time.</div><div><br></div><div>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><br></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"><div><span style="white-space:pre-wrap"> </span>- Doug</div><div><br><blockquote type="cite"><div><div dir="ltr"><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="javascript:_e(%7B%7D,'cvml','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><div><br></div><br><div><blockquote type="cite"><div>On Feb 15, 2016, at 12:24 , Saleem Abdulrasool <<a href="javascript:_e(%7B%7D,'cvml','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="javascript:_e(%7B%7D,'cvml','cfe-dev@lists.llvm.org');" target="_blank">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>
_______________________________________________<br>cfe-dev mailing list<br><a href="javascript:_e(%7B%7D,'cvml','cfe-dev@lists.llvm.org');" target="_blank">cfe-dev@lists.llvm.org</a><br><a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br></div></blockquote></div><br></div></blockquote><br><br>-- <br>Saleem Abdulrasool<br>compnerd (at) compnerd (dot) org<br>