Joel de Guzman <joel@boost-consulting.com> writes:
David Abrahams wrote:
Joel de Guzman <joel@boost-consulting.com> writes:
David Abrahams wrote:
Tobias Schwinger <tschwinger@neoscientists.org> writes:
Why not make is_sequence work reliably? Because it's impossible. It's always going to look for some features of the type being tested that can be present even if the type is not, in fact, a sequence. I don't see why it is impossible. MPL sequences can always specialize is_sequence<T>. is_sequence *can* work reliably 100% of the time:
template <class S> struct is_sequence : mpl::false_ {}; // default
// your specializations here
The problem isn't false negatives, it's false positives. In practice you can probably make it vanishingly unlikely that some random third-party type will pass all the default is_sequence tests, but you can never make it 100% impossible as long as:
a. sequences can be arbitrary types, such as void(int,long,char)
b. is_sequence<S> reporting correctly is not part of the sequence requirements
Is that a or b? or a and b?
I think it's OR.
I believe that the default is_sequence should strictly be mpl::false_: no guessing games.
I think:
a) if you want to make specific types (e.g. RT(A0,A1,...AN)), a sequence, then specialize is_sequence for those.
ODR violations ensue. int(int,long) is a sequence in one TU but not in another.
Sure you can do it for only a limited number of args, but, hey, so do other libraries that provide traits over function types/ member function pointer types, function pointers. Are there other arbitrary types you have in mind that can be sequences? If there are, specialize for them. Explicit is better than implicit, right? I think the guessing game where MPL is trying some heuristics as to how an MPL sequence looks like (e.g. it has a tag typedef, etc), is what's causing us problems. I think it is the wrong approach.
b) If is_sequence is part of MPL's public interface, then it should give reliable results. If that requires b, then so be it.
Right. Which is why I encouraged Aleksey to remove it. I'm surprised it's even documented in the reference manual. -- Dave Abrahams Boost Consulting www.boost-consulting.com