Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Deprecated std::is_literal_type in C++17

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.

like image 213
plasmacel Avatar asked Oct 31 '16 23:10

plasmacel


People also ask

Why is <codecvt> deprecated in C++?

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

Can constexpr member functions have a literal type?

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.

What is the behavior of is_literal_type_V 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".

What does deprecate the is_literal trait mean?

"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."


1 Answers

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.

like image 104
Nicol Bolas Avatar answered Sep 18 '22 20:09

Nicol Bolas