15

With we have fancy new is_invocable and fancy new prvalues that aren't really values.

This permits you to create an object without having to first logically construct it, then elide the construction.

I have run into a problem where using std::is_invocable to test if you can call something, and prvalue rules, seem to collide:

struct no_move {
  no_move(no_move&&)=delete;
  explicit no_move(int) {}
};
void f( no_move ) {}

now can we ask if f can be invoked using a prvalue of type no_move?

f( no_move(1) )

std::is_invocable< decltype(&f), no_move > doesn't work because it uses std::declval<no_move>() which is an xvalue like no_move&& not a prvalue of type no_move.

In this was the same, but guaranteed elision makes some functions callable with an xvalue (i.e., "T&&") and others with prvalues of type T.

Is there an alternative, or do we have to invent our own trait to handle this case?

(In a theoretical world where std::declval<T> returned T instead of T&&, is_invocable would, I believe, do the right thing).

Yakk - Adam Nevraumont
  • 262,606
  • 27
  • 330
  • 524
  • Maybe `std::declval` is now broken, and needs to return exactly what was passed in? – Quentin Jan 09 '18 at 18:38
  • @Quentin `std::declval2` maybe. Or `std2::declval`. But yes, a `std::declval` that returned `T` would make `std::is_invocable` be able to answer the above question. That falls under "invent our own trait" at this point. I wonder if any existing [tag:C++14] code would break if `declval()` returned `T`? – Yakk - Adam Nevraumont Jan 09 '18 at 18:49
  • @Yakk This is pretty strange, I don't know why they just didn't allow `std::declval` to return exactly a `T`; if that were the case then you can still do `declval` to do what current declval does, but by adding the reference for us it makes it impossible to "construct" the value type. – Nir Friedman Jan 09 '18 at 20:01
  • 1
    @NirFriedman Requirements that `T` can be destroyed are then added to `std::declval` based tests. So there is that. – Yakk - Adam Nevraumont Jan 09 '18 at 20:23

2 Answers2

7

You are misusing the Invocable concept. This concept means nothing more than the ability to use std::invoke on the given function and the provided arguments.

You can't do std::invoke(f, no_move(1)), as this would provoke a copy/move of the forwarded argument. It is impossible for a prvalue to be used as a parameter through a forwarded call like invoke. You can pass a prvalue to the forwarding call, but the eventual call to the given function will get an xvalue.

This is a good reason to avoid using immobile types as value parameters in functions. Take them by const& instead.

C++ does not have a type trait to see if a function can be called with specific parameters in the way that you want.

Nicol Bolas
  • 449,505
  • 63
  • 781
  • 982
3

Is there an alternative, or do we have to invent our own trait to handle this case?

Yeah, you'd just have to write your own trait that doesn't use declval. Assuming you have std::is_detected lying around (which I know you certainly do):

template <typename T> T make();

template <typename F, typename... Args>
using invoke_result_t = decltype(std::declval<F>()(make<Args>()...));
//                               ^^^^^^^^^^^^^     ^^^^^

template <typename F, typename... Args>
using is_invocable = std::is_detected<invoke_result_t, F, Args...>;

This way, std::is_invocable<decltype(f), no_move> is false_type, but is_invocable<decltype(f), no_move)> is true_type.

I intentionally use declval<F>() for the function instead of make so as to allow using decltype(f) here. Really, invoke_result_t should be more complicated, and "do the right thing" for pointers to members, etc. But this is at least a simple approximation that indicates the viability of this approach.

Barry
  • 286,269
  • 29
  • 621
  • 977
  • 1
    It's not clear to me how useful this knowledge is, though. – T.C. Jan 09 '18 at 19:57
  • 2
    @T.C. Maybe you have a function template which takes a callable, and the body calls it with a prvalue? It could happen. – Barry Jan 09 '18 at 20:04
  • 1
    @Barry: But the point behind "invocable" is that you're going to call `std::invoke`. That's why member pointers are invocable; because you can use `std::invoke` on them. You can't call them with `()`. – Nicol Bolas Jan 09 '18 at 23:03
  • 2
    @NicolBolas That's because `std::invoke()` was the wrong way to solve the problem, and we should've made pointers-to-members invocable by actually making them invocable. I tried. – Barry Jan 10 '18 at 00:02