You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
not_null comparison functions are missing constexpr #1203
Describe the bug
The comparison operators for not_null such as operator== and operator!= are not declared constexpr, however not_null can be used in constexpr by using .get() instead, so this seems like an oversight.
To Reproduce
#include<gsl/pointers>constexprboolexample_error(gsl::not_null<int*> const a, gsl::not_null<int*> const b) noexcept
{
return a == b; //error
}
constexprboolexample_workaround(gsl::not_null<int*> const a, gsl::not_null<int*> const b) noexcept
{
return a.get() == b.get(); //works
}
Expected behavior
The comparison operators should be constexpr so that the workaround is not necessary.
I suspect this is not an oversight, your workaround requires gsl::not_null<T>::element_type to have a constexpr operator==. Concretely, https://godbolt.org/z/zrqze4sbj will not work with the provided workaround.
From my understanding of the C++ standard, a template function can be marked constexpr as long as at least one template instantiation allows it to be used in constexpr evaluation. When it is instantiated in a way that it can't be used in constant evaluation, it just silently ignores the constexpr specifier. This avoids any need to have a conditional constexpr system in the language, letting the compiler make the determination. Therefore, marking those operators as constexpr should not break any existing code.
Activity
carsonRadtke commentedon Apr 30, 2025
Thanks for reporting this issue!
I suspect this is not an oversight, your workaround requires
gsl::not_null<T>::element_typeto have a constexproperator==. Concretely, https://godbolt.org/z/zrqze4sbj will not work with the provided workaround.LB-- commentedon May 1, 2025
From my understanding of the C++ standard, a template function can be marked
constexpras long as at least one template instantiation allows it to be used in constexpr evaluation. When it is instantiated in a way that it can't be used in constant evaluation, it just silently ignores theconstexprspecifier. This avoids any need to have a conditionalconstexprsystem in the language, letting the compiler make the determination. Therefore, marking those operators asconstexprshould not break any existing code.carsonRadtke commentedon May 2, 2025
Ah! You're right, thanks for teaching me :)
For completeness, it appears the relevant part of the standard is dcl.constexpr#3.2:
I will raise this issue at the next maintainer's sync, and we will discuss how to proceed.
carsonRadtke commentedon May 21, 2025
Maintainer's call: Looks like an oversight, update the signature to be
constexpr