Proposed resolution:

Change General [strings.general] as indicated:

This Clause describes components for manipulating sequences of any literal non-array POD (3.9) type. In this Clause such types are called char-like types, and objects of char-like types are called char-like objects or simply characters.

[ 2010-01-23 Moved to Tentatively Ready after 5 positive votes on c++std-lib. ]

[ 2009-11-04 Howard modifies proposed wording to disallow array types as char-like types. ]

[ 2009-07-28 Alisdair adds: ]

When looking for any resolution for this issue, consider the definition of "character container type" in [defns.character.container]. This does require the character type to be a POD, and this term is used in a number of places through clause 21 and 28. This suggests the PODness constraint remains, but is much more subtle than before. Meanwhile, I suspect the change from POD type to literal type was intentional with the assumption that trivially copyable types with non-trivial-but-constexpr constructors should serve as well. I don't believe the current wording offers the right guarantees for either of the above designs.

Addresses UK 218

Prior to the introduction of constant expressions into the library, basic_string elements had to be POD types, and thus had to be both trivially copyable and standard-layout. This ensured that they could be memcpy'ed and would be compatible with other libraries and languages, particularly the C language and its library.

N2349, Constant Expressions in the Standard Library Revision 2, changed the requirement in 21/1 from "POD type" to "literal type". That change had the effect of removing the trivially copyable and standard-layout requirements from basic_string elements.

This means that basic_string elements no longer are guaranteed to be memcpy'able, and are no longer guaranteed to be standard-layout types:

3.9/p2 and 3.9/p3 both make it clear that a "trivially copyable type" is required for memcpy to be guaranteed to work.

Literal types (3.9p12) may have a non-trivial copy assignment operator, and that violates the trivially copyable requirements given in 9/p 6, bullet item 2.

Literal types (3.9p12) have no standard-layout requirement, either.

This situation probably arose because the wording for "Constant Expressions in the Standard Library" was in process at the same time the C++ POD deconstruction wording was in process.

Since trivially copyable types meet the C++0x requirements for literal types, and thus work with constant expressions, it seems an easy fix to revert the basic_string element wording to its original state.