size of a fusion sequences is signed, should be unsigned

[Mathias Gaunard]

fusion::result_of::size< fusion::vector<int, int> >::type::value is signed, even though it should be size_t.

It appears the problem is two-fold:

• fusion::result_of::size<T>::value is not the same type as fusion::result_of::size<T>::type::value_type
• size of fusion::vector is defined to be a mpl::int_ (it also seems it is the case for all fusion sequences types!)

The fact that this is wrongly signed causes all sorts of warnings.

[Joel de Guzman]

Pedantic. fusion follows MPL's implementation which also uses int (signed). See the implementation of mpl::list for example. And see : http://www.boost.org/doc/libs/1_51_0/libs/mpl/doc/refmanual/forward-sequence.html which specifies size as an Integral Constant with no requirement that it be unsigned. E.g. (mpl::vector):

template<> struct size_impl< aux::vector_tag<1> > {

template< typename Vector > struct apply

: long_<1>

{ };

};

Anyway, if you have a patch (it's library wide), I'd welcome it, but i wonder how it would jive with MPL. E.g.

[Mathias Gaunard]

Fusion is different than MPL in that some standard containers, such as std::array, are also fusion sequences. Standard containers use unsigned sizes, and fusion should follow this.

[Joel de Guzman]

Good point. I'll work on it over the weekend; but I'll very much welcome a patch if you already have one.

[Joel de Guzman]

It turns out that this is not as simple as it seems. Fusion interacts with MPL more than with std::containers. Changing the size to unsigned has vast implications (e.g. we'll have to change at_c and at too. If we do this, in the end, we'll have more warnings with MPL.

If you really want to do this, go ask MPL first. For now, I'm inclined to make this a "wontfix" status.