From: Tobias Schwinger (tschwinger_at_[hidden])
Date: 2006-11-17 08:47:10
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