On Mon, Jun 9, 2014 at 3:39 PM, Stephen Kelly <steveire@gmail.com> wrote:
Nelson, Clark wrote:

>> > Would it be fair to restate your questions as, why are we
>> recommending
>> > something like __has_attribute when we didn't recommend
>> __has_feature?
>
> I was actually hoping someone would provide an answer to that question.

Can we ask the person who proposed it?

I don't see any solid reasons to avoid a function-like attribute detection macro. Yes, it requires preprocessor support beyond just defining some extra macros, but does that actually matter to any implementor? We already crossed that bridge with __has_include.

As for __has_cpp_attribute, it provides a way to query non-standard attributes as well as standard ones. Sure, we could define an encoding such that an implementation can define __has_cpp_attribute_<attribute-scope-token>_<attribute=name> or similar, but...

 1) That's a *lot* of macros. We might be able to get away with the cost of the number of macros that SG10 is currently proposing, but I would be *seriously* concerned about a measurable performance cost (on compiling an empty file, which is not actually an irrelevant concern) of predefining hundreds of __has_attribute macros.

 2) Either of those identifiers could contain underscores, and there is no other separator character that works.

[3) It's ugly.]

> I myself am opposed -- weakly -- to the __has_attribute syntax, or some
> variation thereof, for all the reasons we didn't go with __has_feature in
> the first place, as I explained a couple of weeks ago.

I favor consistency between the feature test and the attribute test.

I agree that there's value in the two being consistent. But I think there are other concerns that we should be weighing.

I'm still not entirely sold on the argument that took us away from something like __has_feature(x), but that ship has sailed. The argument there that holds most weight with me is that features are sometimes provided by the library instead of the language, and it's easy to portably define __cpp_whatever but not so easy to portably extend a magical __has_feature syntax.

I weakly favor __has_foo() for these reasons:

1) For creating the consistency (at least from the users point of view) of
all such tests now and in the future being __has_foo().

For example, __has_builtin(is_final) might solve the problem here:

 http://www.open-std.org/pipermail/features/2014-May/000176.html

See

 http://thread.gmane.org/gmane.comp.compilers.clang.devel/34252


2) For making it harder for users to make mistakes such as

#ifdef __cpp_foo
#endif

when they meant

#if __cpp_foo
#endif

or

#if __cpp_foo > 201404
#endif

or

#if __cpp_foo >= 201404
#endif



I think __cpp_foo is fine because it might be easier to implement. However,
I would request consistent prefixes/namespacing to allow for growth in the
classes of tests recommended (eg builtins):

 http://thread.gmane.org/gmane.comp.lang.c++.isocpp.features/11

Thanks,

Steve.


_______________________________________________
Features mailing list
Features@isocpp.open-std.org
http://www.open-std.org/mailman/listinfo/features