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