RE: [boost] Re: call_traits<int&>::value_type

From: scleary_at_[hidden]
Date: 2003-03-21 13:30:27

> -----Original Message-----
> From: Eric Niebler [mailto:neric_at_[hidden]]
> 
> > > 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'm using the term "by value" to mean an abstract concept.

Let me see if I can rephrase my point of view:
  If you store an "int", you are storing a number.
  If you store an "int &", you are storing a modifiable reference to a
number that is located somewhere else.
  If you store "int &", and return "int", you have not transferred the "by
value" abstract concept -- that is, the return value is just a number, not a
modifiable reference to a number located elsewhere.  [ In this case, you
have "lost value", so to speak.  Heh, heh... :) ]

Whereas, if you store an "int", then you can return by value ("int") or by
reference ("int &").

> 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.

Again, Standard practice generally doesn't apply here, since they just
ignore references completely.

I think that std::vector<int &>::value_type -- if it existed -- would be
"int &".

My point is that if an algorithm wanted to work with a type that is either a
reference or non-reference, then it *should* use call_traits<T>::value_type
for all temporary variables.  And in this case, the "int &" would be the
correct type.

E.g., if an algorithm existed that would return one of the values in a
hypothetical container of references, would you want it to return "int" or
"int &"?

>  I suspect that this is the more common usage
> scenario (<-- blind asseriton), and it is the behavior people 
> would expect.

Most generic software I'm familiar with follows the Standard guideline of
"do not use with reference types".  There are a few exceptions to this rule,
e.g., compressed pair.  These reference-friendly components have made up the
rules as they go, in the way that made the most sense to the authors at the
time... :)

> 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!).

I agree with this totally; I like the idea of two names other than
value_type.  However, I think that they should both resolve to the same type
(currently "value_type").

        -Steve