[boost] Re: [type_traits] request for decayed<T>::type

From: Thorsten Ottosen (nesotto_at_[hidden])
Date: 2005-01-03 16:58:11

"Howard Hinnant" <hinnant_at_[hidden]> wrote in message 
news:E00E478E-5DC5-11D9-BC20-003065D18932_at_twcny.rr.com...
| On Jan 3, 2005, at 1:49 PM, Thorsten Ottosen wrote:
|
| >
| > "Howard Hinnant" <hinnant_at_[hidden]> wrote in message
| > news:C94D8AC6-5C17-11D9-BA03-003065D18932_at_twcny.rr.com...
| > | On Dec 22, 2004, at 8:29 AM, Thorsten Ottosen wrote:
| >
| > |  But with
| > | an eye towards the future, I think decayed will still eventually
| > | improve make_pair:
| > |
| > | template <class T, class U>
| > | inline
| > | pair<typename decayed<typename remove_reference<T>::type>::type,
| > |      typename decayed<typename remove_reference<U>::type>::type>
| > | make_pair(T&& t, U&& u)

[snip]

| > why do you need remove_reference? If its needed, then maybe it should
| > be
| > part of decayed<T>'s behavior.
|
| remove_reference is needed because (in the rvalue reference proposal) T
| may be deduced as a reference type:
|
| A a;
| make_pair(a, a);  // T and U deduced as A&
| make_pair(A(), A());  // T and U deduced as A

ok, I probably need to read up on move-semantics :-) I usually think
of T as the deduced type in expressions like const T& etc.
(To be honest, I don't fully get why the return type of std::forward() and 
std::move() can both be T&&, yet be different :-) )

| I thought about putting remove_reference into decayed, but didn't think
| it fit semantically because references don't decay.  It turns out that
| either I'm mistaken, or CodeWarrior decays references as an extension.
| This compiles for me:

[snip]

I dunno, IFAIK, the term decay is used when an array decays to a pointer and 
the original
type is lost. I'm not sure if that is true with function pointers (ok, you 
loose the original address as a CT-value, but....).

| typedef int A[3];
|
| void foo(int*) {}
|
| typedef void F();
|
| typedef void (*FP)();
|
| void bar(FP) {}
|
| void fun() {}
|
| int main()
| {
|     A a = {};
|     A& ar = a;
|     foo(ar);
|     F f;
|     F& fr = f;
|     bar(fr);
| }
|
| Comeau seems to like it too.  So now it looks to me like the
| remove_reference should go inside decayed, which happily does clean up
| the proposed make_pair a bit.

hm... you can always use a referece where a value is expected: the referenced 
value is
copied. To get the behavior of the make_pair() example, you need to say

void foo(int*&);
void bar(FP&);

| Are we having a good day or what?! ;-)

We sure are :-)

Anyway, the problem of the reference type doesn't seem to be a problem before
we introduce move-semantics; when we do that, decay<T>::type should strip any 
reference
IMO because it will be the most wanted behavior.

br

-Thorsten