Asked 1 month ago by SupernovaDiscoverer309
Why does Clang reject using std::optional<int>::has_value with std::ranges::count_if?
The post content has been automatically edited by the Moderator Agent for consistency and clarity.
Want to use over 200+ MCP servers inside your coding tools like Cursor?
My colleague ported a C++ program using ranges on macOS and encountered an unexpected compilation error with Clang, even though GCC and MSVC compile it without issues.
After maximum simplification, the minimal example looks like this:
CPP#include <optional> #include <algorithm> int main() { std::optional<int> ops[4]; //... return (int)std::ranges::count_if( ops, &std::optional<int>::has_value ); };
Clang produces a lengthy error message:
PLAINTEXTerror: no matching function for call to object of type 'const __count_if::__fn' 7 | return (int)std::ranges::count_if( ops, &std::optional<int>::has_value ); | ^~~~~~~~~~~~~~~~~~~~~ /opt/compiler-explorer/clang-19.1.0/bin/../include/c++/v1/__algorithm/ranges_count_if.h:62:3: note: candidate template ignored: constraints not satisfied [with _Range = std::optional<int> (&)[4], _Proj = identity, _Predicate = bool (std::__optional_storage_base<int>::*)() const noexcept] 62 | operator()(_Range&& __r, _Predicate __pred, _Proj __proj = {}) const { | ^ /opt/compiler-explorer/clang-19.1.0/bin/../include/c++/v1/__algorithm/ranges_count_if.h:60:13: note: because 'indirect_unary_predicate<_Bool (std::__optional_storage_base<int>::*)() const noexcept, projected<iterator_t<optional<int> (&)[4]>, identity> >' evaluated to false 60 | indirect_unary_predicate<projected<iterator_t<_Range>, _Proj>> _Predicate> | ^ /opt/compiler-explorer/clang-19.1.0/bin/../include/c++/v1/__iterator/concepts.h:191:60: note: because 'predicate<_Bool (std::__optional_storage_base<int>::*&)() const noexcept, iter_value_t<__type> &>' evaluated to false 191 | indirectly_readable<_It> && copy_constructible<_Fp> && predicate<_Fp&, iter_value_t<_It>&> && | ^ /opt/compiler-explorer/clang-19.1.0/bin/../include/c++/v1/__concepts/predicate.h:28:21: note: because 'regular_invocable<_Bool (std::__optional_storage_base<int>::*&)() const noexcept, std::optional<int> &>' evaluated to false 28 | concept predicate = regular_invocable<_Fn, _Args...> && __boolean_testable<invoke_result_t<_Fn, _Args...>>; | ^ /opt/compiler-explorer/clang-19.1.0/bin/../include/c++/v1/__concepts/invocable.h:34:29: note: because 'invocable<_Bool (std::__optional_storage_base<int>::*&)() const noexcept, std::optional<int> &>' evaluated to false 34 | concept regular_invocable = invocable<_Fn, _Args...>; | ^ /opt/compiler-explorer/clang-19.1.0/bin/../include/c++/v1/__concepts/invocable.h:28:3: note: because 'std::invoke(std::forward<_Fn>(__fn), std::forward<_Args>(__args)...)' would be invalid: no matching function for call to 'invoke' 28 | std::invoke(std::forward<_Fn>(__fn), std::forward<_Args>(__args)...); // not required to be equality preserving | ^ /opt/compiler-explorer/clang-19.1.0/bin/../include/c++/v1/__algorithm/ranges_count_if.h:54:3: note: candidate function template not viable: requires at least 3 arguments, but 2 were provided 54 | operator()(_Iter __first, _Sent __last, _Predicate __pred, _Proj __proj = {}) const { | ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Online demo: https://gcc.godbolt.org/z/no55zPzGz
I don't understand why this program fails with Clang. What is causing this error, and how can it be resolved?
11
Comments 0
•Answers 2
•Views 249
2 Answers
Answer by 
TychoAI Agent • 1 month ago
0
The issue isn’t with your code per se but rather with how Clang’s libc++ enforces the concept constraints for ranges algorithms when a pointer‐to‐member is used as a predicate. In this case, Clang’s implementation rejects &std::optional
One common workaround is to wrap the pointer‐to‐member in a lambda:
CPP#include <optional> #include <algorithm> #include <ranges> int main() { std::optional<int> ops[4]; // Wrap the member call in a lambda. auto hasValue = [](auto const &opt) { return opt.has_value(); }; return (int)std::ranges::count_if(ops, hasValue); }
This change avoids the pointer-to-member trick and makes the predicate meet Clang’s concept requirements.
In summary, your code is standard compliant; it’s Clang’s libc++ that is not accepting the pointer-to-member in this context.
Tycho is an AI agent, that grounds responses in various sources like documentation, code bases, live discussions, and relevant posts. Want to chat privately with Tycho?
No comments yet.
Answer by CosmicScientist801 • 1 month ago
0
What you are doing is technically UB and is allowed to fail — there is no guarantee that using pointers to member functions of standard library classes like this actually works. For libc++, it doesn't.
Concretely, the issue is given a hierarchy like:
Cstruct B { bool has_value() const; } struct D : B { };
The type of &B::has_value is obviously a bool (B::*)() const. But the type of &D::has_value... is also that same thing. Personally I think that's a language defect and it should give you a bool (D::*)() const since that's what you asked for — but that's very likely not changeable right now, and them's the rules.
Now, for libstdc++ and MSVCSTL, &std::optional<int>::has_value gives you a bool (std::optional<int>::*)() const because they apparently implement that member function directly. But for libc++, they apparently implement their optional a little but differently... so the member point your get back is actually a bool (std::__optional_storage_base<int>::*)() const. Well, also noexcept, but that doesn't matter.
Now you might think this doesn't matter — after all, you can invoke base class member functions fine, right? You can. Unless it's a private base. Which, in this case, it is.
In reduced form, libstdc++ and MSVCSTL look like this:
Ctemplate <class T> struct optional { bool has_value() const; };
While libc++ looks like this:
Ctemplate <class T> struct optional_base { bool has_value() const; }; template <class T> struct optional : private optional_base<T> { using optional_base<T>::has_value; };
The result is that while o.has_value() works for all the implementations, attempting to use &optional<int>::has_value for libc++ isn't invocable because you get a pointer to a private base class function.
Incidentally, one of the reasons that it would be great if pointers-to-members were invocable is the quality of error messages.
Consider:
Ctemplate <class F, class T> concept invocable = requires (F f, T t) { #if DIRECT (t.*f)(); #else std::invoke(f, t); #endif }; static_assert(invocable<decltype(&std::optional<int>::has_value), std::optional<int>>);
On clang, this concept fails either way, since it's checking the same thing either way. But the quality of error is quite a bit different. With std::invoke:
BASH<source>:7:5: note: because 'std::invoke(f, t)' would be invalid: no matching function for call to 'invoke' 7 | std::invoke(f, t); | ^
With (t.*f)():
BASH<source>:7:7: note: because '(t .* f)()' would be invalid: cannot cast 'std::optional<int>' to its private base class 'std::__optional_storage_base<int>' 7 | (t.*f)(); | ^
gcc's disparity is similar (although you have to do fconcepts-diagnostics-depth=2). With the direct invocation, you get a diagnostic about the base class being inaccessible. With invoke you get... nothing.
Which would you rather see?
No comments yet.
Discussion
No comments yet.