Proposed resolution:

In [meta.type.synop] in the group "type properties", just below the line

template <class T> struct is_pod;

add a new one:

template <class T> struct is_literal;

In [meta.unary.prop], table Type Property Predicates, just below the line for the is_pod property add a new line:

[ 2009-10 Santa Cruz: ]

NAD EditorialResolved. Solved by N2984.

[ Addressed in N2947. ]

[ 2009-07 Frankfurt: ]

Beman, Daniel, and Alisdair will work on a paper proposing new type traits.

[ Alisdair is considering preparing a paper listing a number of missing type traits, and feels that it might be useful to handle them all together rather than piecemeal. This would affect issue 719 and 750. These two issues should move to OPEN pending AM paper on type traits. ]

Since the inclusion of constexpr in the standard draft N2369 we have a new type category "literal", which is defined in [basic.types]/p.11:

-11- A type is a literal type if it is:

• a scalar type; or

• a class type (clause 9) with

  • a trivial copy constructor,
  • a trivial destructor,
  • at least one constexpr constructor other than the copy constructor,
  • no virtual base classes, and
  • all non-static data members and base classes of literal types; or
• an array of literal type.

I strongly suggest that the standard provides a type traits for literal types in [meta.unary.prop] for several reasons:

1. To keep the traits in sync with existing types.
2. I see many reasons for programmers to use this trait in template code to provide optimized template definitions for these types, see below.
3. A user-provided definition of this trait is practically impossible to write portably.

The special problem of reason (c) is that I don't see currently a way to portably test the condition for literal class types:

• at least one constexpr constructor other than the copy constructor,