RE: [boost] Submission: typelist

From: Aleksey Gurtovoy (alexy_at_[hidden])
Date: 2001-11-26 22:09:38

> Assuming the comment refers to the names  type_is  and  value_is , the
> intent, of course, is  let_type_be<...>  and  let_value_be<...> , but
> those are just too awkward to type, methinks.  Or maybe not, on second
> thought.  Hmm.

It is! For instance, consider stuffing a type_list by a dozen of integer
values (boost::mpl has value_list for that, but let's ignore it for the sake
of the example); with the names you propose, it will be something like this:

    typedef type_list<
        let_value_be<int,1>, let_value_be<int,7>, let_value_be<int,5>,
        let_value_be<int,2>, let_value_be<int,4>, let_value_be<int,8>, 
        let_value_be<int,9>, let_value_be<int,2>, let_value_be<int,0>,
        let_value_be<int,3>, let_value_be<int,9>, let_value_be<int,1>
        > values;

IMO, there is too much visual clutter here, especially if you consider how
little information the above declaration carries. Or, for example, here is a
compile-time 'for' loop:

    for_loop< let_value_be<int,1>, less_than< mpl::_1, let_value_be<int,1>
>, next<mpl::_1>
        , /* first statement */
        , /* function */
        >

Personally, I find the above much less readable than current

    for_loop< int_t<1>, less_than< mpl::_1, int_t<1> >, next<mpl::_1>
        , /* first statement */
        , /* function */
        >

> For my purposes, I would like the value wrapper (whatever name boost
> ultimately gives it) to handle all the integral types for which the
> language permits non-type template arguments.  I have use for unsigned
> and signed ints of various sizes, as well as for bools, of course, and
> would strongly prefer that a single value wrapper handle them 
> all.  

In principle, I agree. I guess the only reason boost::mpl doesn't have it is
because I never needed more than two of such wrappers - one for int (int_t)
and another one for bool (bool_t). But, as I noted above, the genericity of
a single value wrapper is also its weak side - the template is much more
cumbersome to use, especially in contexts where one ideally would like to
write just an integer constant - 1, 10 or whatever - if the language has
allowed it. Just as an example of how inconvenient this might be - at some
point boost::mpl::int_t<> was called int_value<>, and I changed the name
_mainly_ because even the 9/1 characters ratio (9 "ballast"/ 1-2 informative
ones) was too much.

> The alternative seems to be lots of value wrappers, one per type, 
> and I'm not fond of such proliferation.

Me too. But do you always care what underlying type - short, int or long -
is used to keep your loop counter, if all you want to do is to iterate from
0 to 10? I don't, and in such cases I don't want to write any of those
let_value_be<short,10>, let_value_be<int,10>, or let_value_be<long,0>
instead of simple int_t<10>. Yes, a library should provide a generic wrapper
along the lines you suggest, but a shorter notation for everyday usage is
also required.

> In this context, I find it useful for the value wrapper to encompass
> the type wrapper (by inheritance or by aggregation, it doesn't matter
> to me) so that, if need be, I can inquire as to the wrapped value's
> type.  This, however, appears to conflict with other implementations.
> Some seem not to address this at all, while others seem to prefer that
> the wrapper's reported type (::type) be that of the wrapper itself.

Yes, the latter is what boost::mpl does. It's important to be able to treat
those int_t<>, bool_t<>, etc. "objects" as compile-time nullary functions,
which means supporting the "type" interface in the way you've described
(int_t<N>::type == int_t<N>). As for wrapped value's type - I think it
should be exposed under exactly that name: "value_type" :). 

Hmm, I think I will add this to mpl, and re-define 'int_t<>' in terms of it
too:

    template<typename T, T N>
    struct integral_t
    {
        BOOST_STATIC_CONSTANT(T, value = N);
        typedef T value_type;
        typedef integral_t<N> type;

        // increment/decrement support
        typedef integral_t<N + 1> next;
        typedef integral_t<N - 1> prior;

        // default ctor, conversion operator, etc..
    };

> Thus, there are a few issues beyond naming (as important as that is)
> that ought be discussed, in my opinion, at least briefly.

Yes, and thanks for raising them!

Aleksey