
Boost : 
From: David Abrahams (david.abrahams_at_[hidden])
Date: 20020626 09:26:04
From: "Samuel Krempp" <krempp_at_[hidden]>
> On Thu, 20020620 at 21:14, David Abrahams wrote:
>
> > suggested identity<> before; nobody seemed to get the whole
metafunction
> > idea, so for the record, I don't care all that much what we call it.
>
> If I think of a "identity" metafunction, I would expect it to follow the
> properties of a regular identity :
> "x" is perfectly equivalent to "identity(x)"
>
> But here "T" is equivalent to "identity<T>::type",
> not just "identity<T>".
??? but identity<T> is not equivalent to T; How would that be an identity
metafunction?
> For me, it's not identity.. it's a bijective metafunction allright, but
> not identity.
> I thought injective metafunctions were usually called "wrappers" and in
> fact those wrappers often are as much bijective as this identity<T>
> template. The difference is just that this one is intended to serve as
> as an identity metafunction. (since it's the closest we can get to such
> a thing. there is no "let f(T) = T" possible here..)
I'm a bit lost. Have your looked at the MPL paper Aleksey and I wrote,
particularly the part on the form of metafunctions? Maybe we're not
speaking the same language here.
> So, personnally, I'd rather choose for a weaker, but correct, name based
> on 'wrapper',
> than a more precise, but slightly incorrect name based on 'identity'..
>
> ah, I thought of a clear manifestation of the difference between a true
> identity and this metafunction.
> Mathematically, identity composed with itself is still identity.
> So I'd expect
> identity< identity<T> > to be the exact same thing as
> identity<T>
> And, unless you add a specialisation, it's not the case.
But that's not how an MPL metafunction is invoked.
identity<identity<T>::type>::type == identity<T>::type == T
It's a question of how you define "metafunction". Obviously, definining it
in a way which always wraps is not very useful. Such a metafunction can
never "return" int, for example.
Dave
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk