This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of Resolved status.

### 719. `std::is_literal` type traits should be provided

Section: 20.15 [meta] Status: Resolved Submitter: Daniel Krügler Opened: 2007-08-25 Last modified: 2016-01-28

Priority: Not Prioritized

View other active issues in [meta].

View all other issues in [meta].

View all issues with Resolved status.

Duplicate of: 750

Discussion:

Since the inclusion of `constexpr` in the standard draft N2369 we have a new type category "literal", which is defined in 6.8 [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 20.15.5.4 [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,

[ 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. ]

[ 2009-07 Frankfurt: ]

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

[ Addressed in N2947. ]

[ 2009-10 Santa Cruz: ]

> NAD Editorial Resolved. Solved by N2984.

Proposed resolution:

In 20.15.3 [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 20.15.5.4 [meta.unary.prop], table Type Property Predicates, just below the line for the `is_pod` property add a new line:

Template | Condition | Preconditions
--- | --- | ---
`template <class T> struct is_literal;` | `T` is a literal type (3.9) | `T` shall be a complete type, an array of unknown bound, or (possibly cv-qualified) `void`.