33

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.

plasmacel
  • 8,183
  • 7
  • 53
  • 101

1 Answers1

31

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.

Nicol Bolas
  • 449,505
  • 63
  • 781
  • 982
  • Interestingly I thought that `std::is_literal_type` provides a safe check whether a type can be used in constexpr expressions or not. Nevertheless this is a good answer. – plasmacel Nov 01 '16 at 00:23
  • But could you use this for checking the function arguments, e.g as in [here](https://wandbox.org/permlink/qY9uUeIdGupoGo8R) or would it also break in some cases? – berkus Jul 30 '18 at 14:10
  • @berkus: For what purpose? `constexpr` as applied to a template will *always* be conditional. If you instantiate it with a type that makes the function violate the rules of `constexpr`, then it won't be `constexpr`. So what's the point of the "check"? And if `T` doesn't have a `constexpr` `operator+` (which the check doesn't test), then the function won't be `constexpr` either. So what is the point? – Nicol Bolas Jul 30 '18 at 14:14
  • @NicolBolas not sure anymore, this was some discussion about C++ which I already forgot. I guess this was to provide more sensible error messages when constexprness is violated, but current gcc/clang seem to provide reasonably well-versed messages. Sorry for bothering you. – berkus Sep 02 '18 at 08:06
  • pinging 4 year later, has the replacement been found by WG21? – NoSenseEtAl Aug 28 '20 at 09:10
  • @NicolBolas do concepts allow trick with , like requires { constexpr bool dummy = Bla{}.Lol()++, false;} – NoSenseEtAl Aug 28 '20 at 14:49
  • 1
    @NoSenseEtAl: Actually, I was wrong about the `constexpr` declaration thing in requires expressions. They can only have expressions, not declarations like that. – Nicol Bolas Aug 28 '20 at 14:57
  • 1
    This trait was at least useful in helping users identify if the type they are preparing is literal. After all, the term *is* still used in the current (C++20 draft) spec (literal definition on page 69). Perhaps the baby was thrown out with the bathwater. – user2023370 Nov 05 '20 at 16:50
  • @user2023370: "*This trait was at least useful in helping users identify if the type they are preparing is literal.*" But that's a false negative. Just because a type is literal doesn't mean that a particular `constexpr` use of it will work. If some template code expects the type to be `constexpr` usable in some way, *that* is what the user will have to verify. Giving users false confidence isn't useful. – Nicol Bolas Nov 05 '20 at 16:53