Paul Mensonides wrote:
In more detail: Given a compiler allows CV-qualified functions, these types pass the library without problems; the library detects them properly because top-level cv-qulification is ignored.
I'm not sure what you mean here, but it makes me wary.
The library uses the TypeTraits template 'remove_cv'. I n theory e.g: template<typename T> struct remove_const { typedef T type; }; template<typename T> struct remove_const<T const> { typedef T type; }; should work, shouldn't it? In practice it depends on the compiler, of course.
There is no way to emphasize a query or specification for the cv-qualification of nonmember callable builtin types, which would involve adding overhead for an esoteric and unportable feature.
I assume that you mean compile-time overhead.
What else could I possibly mean here?
If you have support for pointers to cv-qualified member functions, it seems (to me) that the required boilerplate to deal with cv-qualified function types is already there. If you don't have support for cv-qualified member functions, then you should; they are not esoteric at all.
Sure I have (btw. it would've not passed the review without, I guess) - but only for the function types in member function pointers. Implementing things differently would mean a lot of portability-trouble.
The only reason for library support for them (cv-qualified function types), IMO, is completeness. I'm not saying that it is particularly useful.
In a perfect world (where your "remove_member_pointer" template always works) I'ld support them. However, currently I don't see that completeness outweighs its price here. Further I believe it's a good idea to keep the user away from dark corners of the language by design. Regards, Tobias