[cfe-dev] Enabling strong enum extensions under C

Tue Feb 16 13:21:16 PST 2016

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

> On Tuesday, February 16, 2016, Nico Weber <thakis at chromium.org> wrote:
>
>> Is this the only C extension you need for swift? What about -fblocks?
>>
>
> 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.
>
>
>>
>> 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.
>>
>
> 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.
>

That's a good point.

>
>
>> 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
>>>
>>
>>
>
> --
> Saleem Abdulrasool
> compnerd (at) compnerd (dot) org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20160216/29db1f33/attachment.html>