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: [email protected] [mailto:features-bounces@open- > std.org] On Behalf Of Nelson, Clark > Sent: Monday, June 09, 2014 11:37 AM > To: [email protected] > 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) > [email protected] Chair, CPLEX (C SG for parallel language > extensions) > > > _______________________________________________ > Features mailing list > [email protected] > http://www.open-std.org/mailman/listinfo/features _______________________________________________ Features mailing list [email protected] http://www.open-std.org/mailman/listinfo/features
