"Peter Dimov"

The types in l_ are always add_value processed, the types in the other listN that stores references to the arguments at the call site are not. In

bind(f, a1, a2)(b1, b2);

bind(f, a1, a2) creates a list2 that holds the values of a1 and a2, add_value-processed. The call (b1, b2) creates a list2<B1&, B2&> that holds references to b1 and b2.

These are all implementation details. I don't see why you seem so worried about them. In particular, add_value is only present because of the need to support MSVC 6. On a compiler that supports partial specialization, it's possible to use an unadorned list2<A1, A2> as l_. Many other implementation variations are also possible.

Okay, now that I know add_value is a workaround, that clears up a bit of my confusion. I'm working on a typelist variety of bind that works with Loki typelist defined functors. My apologies for my wording of my initial confusion with the bind library. I should have thought about asking why bind was designed thus in a less arrogant way than I initially asked. Hopefully bad first impressions on boost are forgotten faster than bad first impressions with parents. Best, John