On Tuesday, February 16, 2016, Nico Weber <<a href="mailto:thakis@chromium.org">thakis@chromium.org</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Is this the only C extension you need for swift? What about -fblocks?</div></blockquote><div><br></div><div>That's my concern as well.  I can see that it may become convenient to enable more features over time, and having a global toggle for that seems nicer.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div>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></blockquote><div><br></div><div>Though, by doing that, you wouldn't be able to use the same code on GCC even with the same set of extensions.  Explicitly having the flag to control that could prevent that.  Adding a flag to enable features rather than disable them seems easier to manage.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_extra"><div class="gmail_quote">On Tue, Feb 16, 2016 at 3:42 PM, Saleem Abdulrasool <span dir="ltr"><<a href="javascript:_e(%7B%7D,'cvml','compnerd@compnerd.org');" target="_blank">compnerd@compnerd.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On Tuesday, February 16, 2016, Douglas Gregor via cfe-dev <<a href="javascript:_e(%7B%7D,'cvml','cfe-dev@lists.llvm.org');" target="_blank">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>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></span><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><span><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></span><div>I don't think there has been any argument made that this is not a useful extension.</div><span><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></span><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><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>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>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>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>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>
</div></div></blockquote></div><br></div>
</blockquote><br><br>-- <br>Saleem Abdulrasool<br>compnerd (at) compnerd (dot) org<br>