[cfe-dev] Enabling strong enum extensions under C

Tue Feb 16 12:56:53 PST 2016

Is this the only C extension you need for swift? What about -fblocks?

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.

On Tue, Feb 16, 2016 at 3:42 PM, Saleem Abdulrasool <compnerd at compnerd.org>
wrote:

> 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> 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
>>>
>>>
>> _______________________________________________
>> cfe-dev mailing list
>> 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/f909d510/attachment.html>