> > The way call_traits is currently implemented, > > call_traits<int&>::value_type is an int&, > > not an int. > > This is the correct behavior. If you are storing an "int &" and want to > return it by value, you will return an "int &".
This is some new usage of the term "by value" with which I'm not familiar. When I return an "int&", I call that return "by reference". ;-) I don't doubt that there is a use for the current implementation. What I'm saying is that calling it "value_type" is wrong because that term is used already in standard C++, and with a different meaning. call_traits::value_type should be like iterator_traits::value_type -- a non-const, non-reference that can be used to store temporary variables in algorithms and whatnot. I suspect that this is the more common usage scenario (<-- blind asseriton), and it is the behavior people would expect. Since there is a need, as you say, for a typedef that can be used to store a type T and/or return it, perhaps there should be a different typedef, like "member_type" or "return_type" (or both!). Eric _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
