From: Aleksey Gurtovoy (agurtovoy_at_[hidden])
Date: 2002-07-31 16:35:25
Giovanni Bajo wrote:
> Why ::type has been preferred over a more natural ::result? I understand
> that the result is always a type, but I think that using "result" is more
> straightforward to learn and use, since what the type is holding is
> else but the result of the metafunction.
1) '::type' is a more natural counterpart to '::value' than '::result'
(which, in fact, becomes ambiguos if you consider that returning values is
also allowed, although not required);
2) it was already a de-facto standard set by type_traits library, and it
didn't make any sense to break the convention which I consider the most
fitting anyway :).
> Also, at/at_c get (N, Seq) as parameters, in this order. Every other
> algorithm in MPL get (Seq, ...), with the sequence being the first
> parameter. This is very asymmetric, and also a bit hard to debug, since
> compiler just start producing complex errors when you try the natural
> at<Seq, int_c<4> > (ok, at_c<> is easier do debug).
I was considering the change as well, thanks for raising it in public. I'll
swap the order of 'at' parameters in the next revision, unless there will be
a strong opposition to it :).
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk