Hi Aleksey, Aleksey Gurtovoy wrote:
I think the problem is the way mpl::is_sequence is implemented. It tries to detect the presence of a "tag" typedef and a "begin" typedef and concludes that a type is an mpl::sequence if it has both.
Of course it doesn't. The behavior you cite only takes place as a workaround for broken compilers (MSVC <= 7.0) -- which is quite obvious from the code.
Oh sorry :( Should've read the code more closely.
I've complained a long time ago about this.
A link?
T'was a private email. Sorry, can't find it. I'm wrong.
I think this behavior is error prone. It's quite easy to come up with a situation where I have a type T with a "tag" and a "begin" but is not an MPL sequence.
Not that I think it's an implementation that is worth defending, but in all fairness it's hard to imagine a real-world occurrence of a type with nested _typenames_ "tag" and "begin" that wasn't intended to be an MPL sequence. IOW, the workaround is a good enough real-world approximation of the real thing.
Understood.
There must be a better way.
http://www.boost.org/libs/mpl/doc/refmanual/is-sequence.html#expression-sema...
Looks good. I wasn't aware that begin<x> can return void_ when x is not a sequence.
Anyway, in any case, is_sequence<int_<0> >::value should never fail to compile.
Yes, it shouldn't. I'll look into it.
Thanks! I wonder what you have to say regarding the argument on the existence of is_sequence? Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net