[ The usage of the notion of a BaseCharacteristic below might be useful in other places - e.g. to define the base class relation in [refwrap], [func.memfn], or [func.wrap.func]. In this case it's definition should probably be moved to Clause 17 ]

1. Change [meta.rqmts] p.1 as indicated:

   [..] It shall be DefaultConstructible, CopyConstructible, and publicly and unambiguously derived, directly or indirectly, from its BaseCharacteristic, which is a specialization of the template integral_constant (20.6.3), with the arguments to the template integral_constant determined by the requirements for the particular property being described. The member names of the BaseCharacteristic shall be unhidden and unambiguously available in the UnaryTypeTrait.

2. Change [meta.rqmts] p.2 as indicated:

   [..] It shall be DefaultConstructible, CopyConstructible, and publicly and unambiguously derived, directly or indirectly, from an instance its BaseCharacteristic, which is a specialization of the template integral_constant (20.6.3), with the arguments to the template integral_constant determined by the requirements for the particular relationship being described. The member names of the BaseCharacteristic shall be unhidden and unambiguously available in the BinaryTypeTrait.

3. Change [meta.unary] p.2 as indicated:

   Each of these templates shall be a UnaryTypeTrait (20.6.1), publicly derived directly or indirectly from true_type if the corresponding condition is true, otherwise from false_type where its BaseCharacteristic shall be true_type if the corresponding condition is true, otherwise false_type.

4. Change [meta.rel] p.2 as indicated:

   Each of these templates shall be a BinaryTypeTrait (20.6.1), publicly derived directly or indirectly from true_type if the corresponding condition is true, otherwise from false_type where its BaseCharacteristic shall be true_type if the corresponding condition is true, otherwise false_type.

[ 2009-10 post-Santa Cruz: ]

Move to Tentatively Ready.

[ Batavia (2009-05): ]

Alisdair would prefer to factor some of the repeated text, but modulo a corner case or two, he believes the proposed wording is otherwise substantially correct.

Move to Open.

Related to 975 and 1023.

The current wording in [meta.rqmts] is still unclear concerning it's requirements on the type traits classes regarding ambiguities. Specifically it's unclear

• if a predicate trait ([meta.unary], [meta.rel]) could derive from both true_type/false_type.
• if any of the type traits ([meta.rqmts], [meta.unary], [meta.rel]) could ambiguously derive from the same specified result type.
• if any of the type traits ([meta.rqmts], [meta.unary], [meta.rel]) could derive from other integral_constant types making the contained names ambiguous
• if any of the type traits ([meta.rqmts], [meta.unary], [meta.rel]) could have other base classes that contain members hiding the name of the result type members or make the contained member names ambiguous.