[cfe-dev] Enabling strong enum extensions under C

Tue Feb 16 12:42:52 PST 2016

On Tuesday, February 16, 2016, Douglas Gregor via cfe-dev <
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
> <javascript:_e(%7B%7D,'cvml','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
> <javascript:_e(%7B%7D,'cvml','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
>> <javascript:_e(%7B%7D,'cvml','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
>> <javascript:_e(%7B%7D,'cvml','cfe-dev at lists.llvm.org');>
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>
>>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> <javascript:_e(%7B%7D,'cvml','cfe-dev at lists.llvm.org');>
> 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/245b1efd/attachment.html>