> > 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.]
>
> Good points.
>
> I agree that those are more important than consistency, especially
> as it can
> be more consistent in the future if __has_builtin() or anything
> else is
> added in the future.
>
> Then only the language/library feature tests would be
> 'inconsistent' by the
> absence of __has_feature().

As always, consistency is a multi-edged sword. Not everything can be
consistent with everything else; you have to pick your "consistency target"
carefully to achieve the goals you really want.

In my mind, there is a very significant way in which __has_include is
inconsistent with the others: its argument identifies a physical file,
which either is or is not available to be included, objectively.

On the other hand, the argument to __has_feature basically identifies a
concept, and whether an implementation has a feature is often a subjective
call.

The question of whether an implementation recognizes an attribute with a
given name can be answered objectively, I suppose, but it seems to me
there's still some wiggle room, because the attribute may not do exactly
what I think it should do. But then I suppose it's theoretically possible
for an implementation to have a header named <optional> whose contents do
what <stddef.h> is supposed to do.

For me, the only thing that's really consistent between __has_include,
__has_feature and __has_attribute is that their syntaxes all use
parentheses. And for my money, that puts __has_feature and __has_attribute
at a (slight) disadvantage compared with just constructing a macro name
using an underscore delimiter instead.

Clark