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?
Why would it use __has_extension(X) with the semantics described
above, then?

> 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