The problem of libstdc++‘s implementation of std::declval

Question

Unlike libc++ or MSVC-STL that only declares the function signature of std::declval, libstdc++ defines the function body for std::declval, and uses static_assert internally to ensure that it must be used in unevaluated contexts:

template<typename _Tp, typename _Up = _Tp&&>
_Up 
__declval(int);

template<typename _Tp>
_Tp 
__declval(long);

template<typename _Tp>
auto 
declval() noexcept -> decltype(__declval<_Tp>(0));

template<typename _Tp>
struct __declval_protector {
  static const bool __stop = false;
};

template<typename _Tp>
auto 
declval() noexcept -> decltype(__declval<_Tp>(0)) {
  static_assert(__declval_protector<_Tp>::__stop,
    "declval() must not be used!");
  return __declval<_Tp>(0);
}

When we try to evaluate the return value of std::declval, this static_assert will be triggered:

auto x = std::declval<int>(); // static assertion failed: declval() must not be used!

But I found that in this implementation, the following code will also be rejected because static_assert fails (godbolt):

#include <type_traits>

template<class T>
auto type() { return std::declval<T>(); }

using T = decltype(type<int>());

But it seems that std::declval is still used in an unevaluated context since we have not actually evaluated it.

Is the above code well-formed? If so, is it a library implementation bug? How does the standard specify this?

`std::declval` is only allowed in unevaluated expressions. `return std::declval();` is not an unevaluated expression. I think clang is right to reject this code. — NathanOliver, Jul 30 '21 at 12:05
see here for what an unevaluated context is: https://stackoverflow.com/questions/35088599/what-are-unevaluated-contexts-in-c. A function that you don't call is not an unevaluated context — 463035818_is_not_an_ai, Jul 30 '21 at 12:06
Note that libstdc++'s implementation of `std::declval` would make the program ill-formed, no diagnostic required outside of the implementation of the std library. But the same might be true of the other ones (the requirement that all specializations must have a legal instantiation; `__declval_protector` attempts to work around that, but being sneaky doesn't make it well formed). This is not actually a problem, because the standard places no restrictions on the contents of std header files. — Yakk - Adam Nevraumont, Jul 30 '21 at 17:38
The issue is fixed for MSVC: https://github.com/microsoft/STL/blob/f75c7f596c7b491168fefb5eff5164ab7ae36867/stl/inc/type_traits#L135-L137 . The fix will be available in VS 2022 — Alex Guteniev, Aug 17 '21 at 09:44

score 10 · Accepted Answer · answered Jul 30 '21 at 12:07

The example is ill-formed, because the restriction for std::declval is actually on the expression where declval is named, not on whether the abstract virtual machine would actually evaluate its call.

The requirement on std::declval is [declval].2

Mandates: This function is not odr-used ([basic.def.odr]).

where "Mandates" means ([structure.specifications]/(3.2))

Mandates: the conditions that, if not met, render the program ill-formed.

In [basic.def.odr]/7:

A function is odr-used if it is named by a potentially-evaluated expression or conversion.

And in [basic.def.odr]/2:

An expression or conversion is potentially evaluated unless it is an unevaluated operand ([expr.prop]), a subexpression thereof, or a conversion in an initialization or conversion sequence in such a context.

Note the expression type<int>() in the last line is an unevaluated operand. But the distinct expression std::declval<T>() in the instantiated definition of type is potentially evaluated. It doesn't matter that ignoring that, it would not actually be evaluated.

So actually the libc++ and MSVC-STL implementations are incorrect, because an ill-formed program should be diagnosed unless otherwise noted.

The problem of libstdc++‘s implementation of std::declval

1 Answers1