[cfe-dev] Enabling strong enum extensions under C

[Douglas Gregor via cfe-dev]

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

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;

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.

	- Doug

> 
> Nico
> 
> On Mon, Feb 15, 2016 at 11:26 PM, Jordan Rose via cfe-dev <cfe-dev at lists.llvm.org <mailto: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 <mailto: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 <mailto: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

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