My comments should be taken with several grains of salt, but ...

I recall discussion (Kelly's?) of the real complications where an implementation asserts has_xxxx but the systems people need to be able to over-ride that assertion. That sounds easier to do with a macro naming syntax that can be #undef'd when necessary.

Therefore I'm mildly opposed to has_attribute and has_feature.

> -----Original Message-----
> From: features-bounces_at_[hidden] [mailto:features-bounces_at_open-
> std.org] On Behalf Of Nelson, Clark
> Sent: Monday, June 09, 2014 11:37 AM
> To: features_at_[hidden]
> Subject: Re: [SG10] __has_[cpp_]attribute
>
> > > 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.
>
> I put __has_cpp_attribute into the document based on my sense of the
> March
> 17 meeting, which I recorded as "some sentiment" in favor. But before
> this
> is discussed in EWG next week, I'd like to have a clearer idea of the
> consensus within SG10. So please reply with your position.
>
> 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.
>
> --
> Clark Nelson Vice chair, PL22.16 (ANSI C++ standard
> committee)
> Intel Corporation Chair, SG10 (C++ SG for feature-testing)
> clark.nelson_at_[hidden] Chair, CPLEX (C SG for parallel language
> extensions)
>
>
> _______________________________________________
> Features mailing list
> Features_at_[hidden]
> http://www.open-std.org/mailman/listinfo/features