According to cppreference, the trait std::is_literal_type
is deprecated in C++17. The question is why and what is the preferred replacement for the future to check whether a type is a literal type.
It was deprecated because it is not considered “the best way to address transcoding”, for several reasons, such as lacking of default error handling mechanisms for attacks through ill-formed UTF, obscure specifications, lack of portability, etc. For more information, see Deprecating <codecvt>.
Only literal types may be used as parameters to or returned from constexpr functions. Only literal classes may have constexpr member functions. ↑ Alisdair Meredith. "Deprecate the is_literal Trait". Deprecating Vestigial Library Parts in C++17.
The behavior of a program that adds specializations for is_literal_type or is_literal_type_v (since C++17) is undefined. Only literal types may be used as parameters to or returned from constexpr functions. Only literal classes may have constexpr member functions. ↑ Alisdair Meredith. "Deprecate the is_literal Trait".
"Deprecate the is_literal Trait". Deprecating Vestigial Library Parts in C++17. "The is_literal type trait offers negligible value to generic code, as what is really needed is the ability to know that a specific construction would produce constant initialization."
As stated in P0174:
The
is_literal
type trait offers negligible value to generic code, as what is really needed is the ability to know that a specific construction would produce constant initialization. The core term of a literal type having at least one constexpr constructor is too weak to be used meaningfully.
Basically, what it's saying is that there's no code you can guard with is_literal_type_v
and have that be sufficient to ensure that your code actually is constexpr. This isn't good enough:
template<typename T> std::enable_if_t<std::is_literal_type_v<T>, void> SomeFunc() { constexpr T t{}; }
There's no guarantee that this is legal. Even if you guard it with is_default_constructible<T>
that doesn't mean that it's constexpr default constructible.
What you would need is an is_constexpr_constructible
trait. Which does not as of yet exist.
However, the (already implemented) trait does no harm, and allows compile-time introspection for which core-language type-categories a given template parameter might satisfy. Until the Core Working Group retire the notion of a literal type, the corresponding library trait should be preserved.
The next step towards removal (after deprecation) would be to write a paper proposing to remove the term from the core language while deprecating/removing the type trait.
So the plan is to eventually get rid of the whole definition of "literal types", replacing it with something more fine-grained.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With