[cfe-dev] Enabling strong enum extensions under C

[Nico Weber via cfe-dev]

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.

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20160216/de02f4e0/attachment.html>