On Fri, May 3, 2013 at 10:26 PM, Jens Maurer <Jens.Maurer_at_[hidden]> wrote:

> On 05/03/2013 11:34 PM, Richard Smith wrote:
> > This looks like a great start.
> >
> > 1) Clang has separate __has_feature(X) and __has_extension(X) macros.
> > The former determines whether the feature is available as part of the
> > enabled language standard in the current compilation, and the latter
> > determines whether it's available (possibly as an extension) in the
> > current compilation. The difference is that use of __has_extension(X)
> > features may generate warnings (and, with -Werror or
> > -pedantic-errors, may generate errors).
> >
> > Which of these is the behavior we want for these feature-test macros?
> > In my experience, __has_feature(X) is what you want when determining
> > whether to use a language feature in normal code, but
> > __has_extension(X) is what you want when determining whether to use a
> > language feature in a system header.
>
> I would expect that a system header tried hard to avoid warnings or
> errors?
>

Typically, warnings are suppressed in system headers, so they're free to
(and often do) use any facilities we provide as an extension without
worrying about users seeing diagnostics.


> Why would it use __has_extension(X) with the semantics described
> above, then?


Because it wants to provide extra functionality (for instance, move
constructors) even when building in a language which doesn't officially
support that functionality.


> > 2) At what point will we consider these names stable enough for
> > compiler vendors to start providing them? Are we OK with compilers
> > starting to define these today? (FWIW, I think this is fine.)
>
> This raises a good point: Versioning of the list. Currently, it's
> just Clark's ideas, not coordinated with anyone. I'd like to see
> at least an N-numbered paper and possibly a "letter ballot"
> equivalent [i.e. a table of interested people with yes/no/abstain]
> recorded on some wiki page, or a teleconference, to "ok" a given
> version of the list. Remember that we can't change the names
> going forward.
>
> > 3) Can we split a __cpp_decltype_auto out of
> > __cpp_return_type_deduction? These are essentially two separate,
> > orthogonal features, which just happen to have been added in the same
> > paper.
>
> Sounds like a good idea.
>
> > 4) I agree with Jens that a feature-test macro for __cpp_new_merging
> > is unlikely to add any value.
>
> Thanks for agreeing with me :-)
>
> Jens
> _______________________________________________
> Features mailing list
> Features_at_[hidden]
> http://www.open-std.org/mailman/listinfo/features
>