Richard Smith wrote:
Tobias Schwinger wrote:
Now folks complain more about the tags than before. Worse than that, I haven't been presented a single clearly superior alternative!
What's wrong with separate traits for these? So far as I can see, you only need four (plus one per platform specific calling convention):
is_variadic<T>::value is_const_member_function<T>::value is_volatile_member_function<T>::value is_default_cc<T>::value
These seem much more in the spirit of the existing type traits in Boost.
By your own admission, "typical use cases will not require that a tag argument is ever given *by design*", so requring a library user to use mpl::and_ (and perhaps mpl::not_) to fold these in on those atypical use cases that require this information can't be much of a burden.
Two things: 1. How to specify the properties for type synthesis? You proposed to strip it out, but I think that the compromising the symmetry of the library is far to high of a price for unspecified aesthetical reasons. 2. The primary interface would be "shape shifting" based on the configuration: is_fastcall_cc is_stdcall_cc is_*_cc which, is at least as ugly (not to say uglier) as tag types, IMO. Further: none of the reviewers (except Doug Gregor, who was talking about the issue in the very specific context of merger with another library) did answer the following question: What's wrong with the tag types (other than personal taste) in the first place? A "reject" vote for a matter of personal taste is pretty tough, IMO. But sadly it wouldn't surprise me much after reading some of the material from the GIL review... Regards, Tobias