Boost logo

Boost :

From: David B. Held (dheld_at_[hidden])
Date: 2004-04-02 14:49:58

"Rob Stewart" <stewart_at_[hidden]> wrote in message
> From: David Abrahams <dave_at_[hidden]>
> >
> > Technically one can never say "class template foo is a traits
> > template" or "class template foo is a policy" without examining
> > how it's used. There's no fundamental reason that the same
> > class template can't be used in both ways, so for any given
> > class template, there may be no either/or answer.
> I don't quite agree. A policy class is only that because it is a
> template parameter. Whether a class that is passed as a policy
> to some template happens to be a traits class is immaterial.
> So, in the context of the template, the template parameter is a
> policy class and that may correspond to a traits class in a
> particular specialization, but that doesn't make the traits class
> a policy class. Does that make sense?

Ah, and here I think is the sticking point. I think we are thinking of
traits and policies as complements/duals of each other. That is
certainly a natural way for brains to dichotomize things. But, after
writing my definitions and seeing more discussion, I am led to the
conclusion that traits and policies are fundamentally different things.

That is, I claim that "traitness" is a property of a *type*, but
"policyness" is a property of a *usage of a type*. Thus, if a type
is a metafunction that is specialized for various inputs, then it is
a trait. But any type that provides configuration type data or
behavior to a client metafunction is a policy. What that means is
that "traitness" is a meta-static property, and "policyness" is a
meta-dynamic property. That is, you can always say: "type X is
a trait" or "type X is not a trait", without any context. But you can
only say "type X is being used as a policy in context Y" or the

Is char_traits<> a trait? Yes. Is it a policy? Depends. Is
allow_conversion<> a policy? The only sensible way it is used, it
is. Is it a trait? No, because it is not even a metafunction, let alone
customized for its inputs. So here are my "complete" definitions
of "trait" and "policy":

    1. A trait T is a metafunction of the client type X such that T
        is customized over various X.

    2. A client type X is a metafunction of a policy P such that X
        is customized over various P.

Stated that way, I guess I'm going to contradict myself and say
that they are duals of each other in some sense. Rob makes the
observation that traits are usually global, while policies are usually
local. I think that is nicely implied by my definitions above.

A corollary is that T is a locus of customization. That is, you collect
the implementation variations within specializations of T. With
policies, the client type X is the locus of customization, and the
specializations are spread out over the space of Ps. So really,
traits and policies trade off whether you place the customization
within one type, or spread it out over many types. And, of course,
they may interact and overlap for those curious "traits policies"
(or is that "policy traits"? ;).

Note that I make no distinction about whether T does or does not
include behavior (nor for P). I think that's a red herring.


Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (
Version: 6.0.581 / Virus Database: 368 - Release Date: 2/9/2004

Boost list run by bdawes at, gregod at, cpdaniel at, john at