[cfe-dev] Enabling strong enum extensions under C

Tue Feb 16 13:49:54 PST 2016

> On Feb 16, 2016, at 12:56 PM, Nico Weber <thakis at chromium.org> wrote:
> 
> Is this the only C extension you need for swift?

I believe that it’s the only non-attribute extension not covered by an existing flag.

> What about -fblocks?

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.

> 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.

Swift’s Clang importer can certainly use -std=gnu<whatever>, and keep fixed underlying types out of -std=c<X>.

	- Doug

> 
> On Tue, Feb 16, 2016 at 3:42 PM, Saleem Abdulrasool <compnerd at compnerd.org <mailto:compnerd at compnerd.org>> wrote:
> On Tuesday, February 16, 2016, Douglas Gregor via cfe-dev <cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>> wrote:
> 
>> On Feb 16, 2016, at 6:46 AM, Nico Weber via cfe-dev <cfe-dev at lists.llvm.org <>> wrote:
>> 
>> 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.
> 
> We certainly can add -fswift-extensions, but it’s a level of divergence I’d like to avoid.
> 
> 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.
>  
> 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:
> 
> 	enum {
> 	  ColorRed,
> 	  ColorGreen,
> 	  ColorBlue
> 	};
> 	typedef int32_t ColorType;
> 
> 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:
> 
> 	typedef enum ColorType {
> 	  ColorRed,
> 	  ColorGreen,
> 	  ColorBlue	
> 	} ColorType;
> 
> Fixed underlying types address this problem with syntax that is unambiguous in C and the obvious semantics:
> 
> 	typedef enum ColorType : int32_t {
> 	  ColorRed,
> 	  ColorGreen,
> 	  ColorBlue	
> 	} ColorType;
> 
> I don't think there has been any argument made that this is not a useful extension.
>  
> 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.
> 
> As Chris mentioned, this is likely to take a long time.
> 
> 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.
> 
> 	- Doug
> 
>> 
>> Nico
>> 
>> On Mon, Feb 15, 2016 at 11:26 PM, Jordan Rose via cfe-dev <cfe-dev at lists.llvm.org <>> wrote:
>> Hi, Saleem. I think you've conflated two features here:
>> 
>> - ObjC's implementation of C++11's "enums with fixed underlying types" feature.
>> - 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.
>> 
>> I think these should be discussed separately, and I think you're more interested in the former right now. Is that correct?
>> 
>> If so, this certainly seems reasonable to me. Like many other things added to the language, we can treat this as a feature of Objective-C and C++ >= 11, and an extension 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.
>> 
>> Jordan
>> 
>> 
>>> On Feb 15, 2016, at 12:24 , Saleem Abdulrasool <compnerd at compnerd.org <>> wrote:
>>> 
>>> Hi,
>>> 
>>> Swift has generally been well-received, and there is active development
>>> occurring to support it well on other targets, including ports to Android and
>>> FreeBSD.  As part of this work, it has become apparent that certain (objc)
>>> extensions would be extremely useful to have available when working with swift.
>>> 
>>> One such feature in particular is CF_ENUM/CF_OPTIONS support.  This is currently
>>> only enabled under Objective-C compilation.  This extension provides strong
>>> enums similar to C++11's enum class.  In order to improve Swift's
>>> interoperability, it would be useful to enable this in C as well.
>>> 
>>> To explain the utility more concretely, enabling this extension allows for
>>> cleaner cross-platform code in Swift.  Having differences in the C variant means
>>> that the code needs to be conditionalised via '#if' checks, making it difficult
>>> to follow.  Most swift code is written against a C variant which enables strong
>>> enumerations by default, and this results in a difference in the language
>>> constructs based on the environment.  Most documentation and example code are
>>> written assuming this as well and it can be very difficult to diagnose why code
>>> works in one environment but not the other.  This disparity makes interfacing
>>> with libraries a challenging endeavour for developers.
>>> 
>>> The question is what is the best option for enabling this extension on platforms
>>> where we have non-clang compatibility involved (e.g. Linux).  Should we just be
>>> aggressive and introduce additional compiler specific extensions without
>>> considerations for `-std`, vend a custom standard, or introduce a feature flag
>>> to control these additional extensions that are useful for Swift.
>>> 
>>> There are pros and cons to each option, and this email is intended to open a
>>> dialogue around which option would be the best long term for clang and the
>>> language in general.
>>> 
>>> Thanks!
>>> 
>>> -- 
>>> Saleem Abdulrasool
>>> compnerd (at) compnerd (dot) org
>> 
>> 
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at lists.llvm.org <>
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev <http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev>
>> 
>> 
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at lists.llvm.org <>
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev <http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev>
> 
> 
> 
> -- 
> Saleem Abdulrasool
> compnerd (at) compnerd (dot) org
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20160216/0ceb940d/attachment.html>