A number of National Body Comments [P0488R0] (GB68, US155, US154) point out that the application of "literal type" to a number of locations is too strict, and not what is intended as a constraint for the type.
This proposal alters the wording for a number of components to the library, however the changes are largely editorial.
Note for editor: Remove the note in 20.8.3¶1[any.class]:
[ Note: any is not a literal type. — end note ]
Note for editor: Replace the following paragraphs in 24.6.1.1 [istream.iterator.cons]:
¶1: Effects: Constructs the end-of-stream iterator. If T is a literal typeis_trivially_default_constructible_v<T> is true, then this constructor shall beis a constexpr constructor.
¶5: Effects: Constructs a copy of x. If T is a literal typeis_trivially_copy_constructible_v<T> is true, then this constructor shall beis a trivial copy constructor.
¶7: Effects: The iterator is destroyed. If T is a literal typeis_trivially_destructible_v<T> is true, then this destructor shall beis a trivial destructor.
Note for editor: Alter 20.6.4[optional.nullopt] to reflect the following changes:
20.7.4[optional.nullopt]:Type nullopt_t shall not have a default constructor. It shall be a literal type. Constant nullopt shall be initialized with an argument of literal type.
Note for the editor:The usage of literal type in 26.5¶2[complex.numbers] is correct, and should remain(quoted for informational and review purposes).
26.5¶2[complex.numbers]:The specializations complex<float>,complex<double>, and complex<long double> are literal types (3.9).
Revision 0:
[N4606] C++17 CD Ballot Document. Available online at www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/n4606.pdf.
[P0488R0] National Body Comments Available online at http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0488r0.pdf.