-----Original Message----- From: boost-users-bounces@lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Peter Dimov
Andy Little wrote:
What is the problem with the result of plus<int_<A>,int_<B>> being int_<A+B> ?
How does the specification of mpl::plus look like in your proposed model?
I don't think *this* it is necessarily difficult to implement as Andy would prefer. However, global application (to the MPL) of the underlying concept represents a major refactoring and the result would most likely be a lot slower. Dave was referring to the sequence identity problem because it is exactly the same kind of thing. There is a dinstinction between types on which metaprogramming operates (such as 'int' or 'const MyClass') and the types of metaprogramming constructs themselves. The latter need only be structurally compatible with the concept (i.e. the archtype or the Plutonic form of the structure). If the MPL starts making guarantees that metatypes (e.g. a 'vector', a 'list', an 'int_<A>') can be used as a non-metatype, it will lead to either 1) a combinatorial explosion of code or 2) a drastic efficiency hit (because the library will be explicitly rewriting structures after they are built). Granted, if this was done for integral wrappers only, the combinatorial explosion wouldn't be too terribly bad. IMO, you don't need wrappers for every integral type in this domain, you only need an integer wrapper (around 'long'), a natural wrapper (around 'unsigned long'), and a Boolean (around 'bool'). *But*, it still comes down to a more fundamental issue.... Should the library endorse the use of the types of metaprogramming constructs themselves as non-metatypes? I'd say it shouldn't. If you need that for 'int_<A+B>' (e.g.) then say 'int_<plus<int_<A>, int_<B> >::value>' Regards, Paul Mensonides