Aleksey Gurtovoy wrote:
Both sides of this behavior steam from nongenericity of the 'at' metafunction, which treats Associated Sequences differently from "plain" Forward Sequences [1].
'joint_view' of two maps is simply a Forward Sequence [2], which changes the 'at' semantics from a value lookup in the associative sequence to an equivalent of 'deref< advance< begin<s>::type,n >::type
::type'. Thus the result you observed: 'at<JointMap, int_<2> >::type' simply returns JointMap's third element.
This can be definitely argued to be a design bug.
However, suppose that requesting the map's value by key was spelled differently, say, 'get'. Well, even in this case, unless the 'joint_view' of two Associated Sequences becomes in an Associated Sequence as well, applying 'get' to JointMap still won't work -- although you'd most likely get an error instead of a puzzling result.
All in all, to get the behavior you want with the current library you need to actually merge two maps into a third one.
[1] http://boost.org/libs/mpl/doc/refmanual/at.html [2] http://boost.org/libs/mpl/doc/refmanual/joint-view.html
This is also one of the reasons why Fusion deviates a bit from MPL. In Fusion, we have both at<N> and at_key<K>. Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net