Nelson, Clark wrote: > OK, I have added entries for all of the library issues mentioned by > Alisdair. No macro for gets, but macros for the other three. For two of > them, no one gave any feedback, but I went ahead and filled in the obvious > values. They are all marked by editorial question marks. > > Besides a few tweaks, those are the only changes since I posted it on > April Fool's Day. I plan to put the result (attached) into the mailing as > N4030, mainly so we can get more eyes on the __has_cpp_attribute feature. >
Hi, Thanks for working on this. I have followed this paper for a while, and I notice that while it recommends a __has_include() function-like macro, and a __has_cpp_attribute() function-like macro, it does not recommend a __has_feature() function-like macro, as is used in Clang. As an implementation is using it, it might make sense to add why it is not recommended. I assume it was discussed long ago, but the reasoning not recorded in the paper. I can imagine two possible reasons for not recommending it: 1) It is desirable to have non 0/1 values available for each feature (why is that desirable?), whereas __has_feature() would only expand to 0 or 1. 2) While __has_feature() might be suitable for language features it is deemed unsuitable for library features. There is a desire to use a single interface for both types of features (Why is that desired?). If (1) was a valid reason, then it would apply similarly to __has_cpp_attribute for consistency, so I assume the only actual reason is (2)? Thanks, Steve. _______________________________________________ Features mailing list [email protected] http://www.open-std.org/mailman/listinfo/features
