> This looks like a great start.

Thanks.

> 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.

FWIW, I have always taken the view that, when an implementer implements a feature, he should define the macro. To me, that sound like the semantics you describe as "__has_extension". (And also FWIW, I personally can't see the value of the semantics you describe for "__has_feature".)

> 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. There's a decent chance that Clang 3.3 will ship with the former but not the latter.

We can, and should, do whatever we think makes sense -- including discouraging people from putting separate, orthogonal features into a single paper in the future, if we think that makes sense.

Clark