Thursday, February 19, 2015

SFINAE std::result_of? Yeah, right!

Return type deduction pre-decltype and auto could really make one mad. Back then, if you wanted a function object, you had to make it "adaptable", meaning it had to inherit from std::unary_ or binary_function and define its first_argument_type, second_argument_type, and result_type. There had been no concept of "transparent functors" allowing us to pass polymorphic functions to higher order functions (like std::plus<> to std::accumulate). For an example of programming in these dark ages, check out the FC++ FAQ.

Just to recap, SFINAE stands for Substitution Failure Is Not An Error. It's the rule that lets you define two overloads of a function such that and one returns decltype(f(x)) and the other decltype(g(x)), if f(x) can't be evaluated, that's not an error. If g(x) can't. either, that's OK too, as long one one of the two can be for any given x.

And so came decltype and it let us do never-before seen, amazing things, right? Well, yes, we could write things like this:
template<class X>
constexpr auto append_blah(X& x) -> decltype(x + "blah")
{
  return x + "blah";
}

int main() {
  append_blah("nah");
}
Obviously, since "nah" += "blah" isn't valid, this will fail to compile, but we'll get a nice, easy to read error message, right? Nah!
auto.cpp: In function `int main()`:
auto.cpp:11:20: error: no matching function for call to `append_blah(const char [4])`
   append_blah("nah");
                    ^
auto.cpp:11:20: note: candidate is:
auto.cpp:5:16: note: template<class X> constexpr decltype ((x + "blah")) append_blah(X)
 constexpr auto append_blah(X x) -> decltype(x + "blah")
                ^
auto.cpp:5:16: note:   template argument deduction/substitution failed:
auto.cpp: In substitution of `template<class X> constexpr decltype ((x + "blah")) append_blah(X) [with X = const char*]`:
auto.cpp:11:20:   required from here
auto.cpp:5:47: error: invalid operands of types `const char*` and `const char [5]` to binary `operator+
That's GCC's output--more error than code! Even with the most relevant section bolded, it's a mess. Clang does a better job, though.
auto.cpp:12:3: error: no matching function for call to 'append_blah'
  append_blah("nah");
  ^~~~~~~~~~~
auto.cpp:6:16: note: candidate template ignored: substitution failure [with X = char const[4]]: invalid operands to binary expression ('char const[4]' and 'const char *')
constexpr auto append_blah(X& x) -> decltype(x + "blah")
               ^                               ~~
So now, thanks to N3436, that the standard dictates that std::result_of be SFINAE, too. Has the situation for GCC improved? First, the new source:
template<class X>
constexpr std::result_of_t<std::plus<>(X, const char*)>
append_blah(X x) {
  return std::plus<>{}(x, "blah");
}

int main() {
  append_blah("nah");
}
And GCC's output:
auto.cpp: In function `int main()`:
auto.cpp:12:20: error: no matching function for call to `append_blah(const char [4])`
   append_blah("nah");
                    ^
auto.cpp:12:20: note: candidate is:
auto.cpp:5:16: note: template<class X> constexpr std::result_of_t<std::plus<void>(X, const char*)> append_blah(X)
 constexpr auto append_blah(X x)
                ^
auto.cpp:5:16: note:   template argument deduction/substitution failed:
While the error message certainly gotten shorter, GCC no longer tells us why the function failed to compile, only that it was a candidate and "template argument deduction/substitution failed"--it doesn't even give us the type of X! SFINAE doesn't mean better diagnostics, it's just an overloading technique. Still, if it decreases the readability of error messages, then having many overloads, all failing, just compounds the problem.

But clang does better, right?
auto.cpp:12:3: error: no matching function for call to 'append_blah'
  append_blah("nah");
  ^~~~~~~~~~~
auto.cpp:5:16: note: candidate template ignored: 
  substitution failure [with X = const char *]: 
    no type named 'type' in `std::result_of<std::plus<void> (const char *, const char *)>`
constexpr auto append_blah(X x)
               ^
1 error generated.
Better, yes, but not great. We still don't know why it failed. If you have deeply nested function calls, but your top-level function guarantees a return of std::result_of_t<invalid-expression>, you'll never know why it failed to compile because result_of doesn't actually evaluate the semantics; it just checks the signatures and spits out that result_of has no type.

There simply must be a way of writing this such that GCC and clang will give a minimal, correct diagnosis of the problem, right? Well, let's try using auto as our return type.
template<class X>
constexpr auto append_blah(X x) {
  return x + "blah";
}

int main() {
  append_blah("nah");
}
What does GCC have to say?
auto.cpp: In instantiation of `constexpr auto append_blah(X) [with X = const char*]`:
auto.cpp:11:20:   required from here
auto.cpp:7:12: error: invalid operands of types `const char*` and `const char [5]` to binary `operator+`
   return x + "blah";
            ^
Wow, straight to the point and totally accurate! We get a nice, minimal trail of what GCC had to instantiate to find the error, but not a hard-to-follow mess of output. How does clang handle it?
auto.cpp:7:12: error: invalid operands to binary expression (`const char *` and `const char *`)
  return x + "blah";
         ~ ^ ~~~~~~
auto.cpp:11:3: note: in instantiation of function template specialization `append_blah<const char *>` requested here
  append_blah("nah");
  ^
1 error generated.
Again, exactly what I wanted!

So in terms of getting good and useful error messages, auto or decltype(auto) gives the best, followed by decltype, and result_of gives the absolute worst. The problem is that auto can't participate in SFINAE, so you can't overload a set of functions on auto and that leaves you with std::enable_ifstd::result_of, or decltype.

Before concluding, let's look at a slightly more obfuscated example.
#include <functional>

constexpr struct plus_f {
  template<class X, class Y>
  constexpr auto operator() (X&& x, Y&& y) const
    -> decltype(std::declval<X>() + std::declval<Y>())
  {
    return std::forward<X>(x) + std::forward<Y>(y);
  }
} plus{};

template<class X>
constexpr auto append_blah(X x) -> decltype(plus(x, "blah")) {
  return plus(x, "blah");
}

int main() {
  append_blah("nah");
}
Now, in order to find the error, the compiler has to go just two levels deep, through append_blah, then to plus_f, and evaluage x + "blah". But will the error message go that deep? We know that if we used std::result_of, it would just say that result_of<plus_f(X, const char*)> has no 'type'. But this is decltype!

First, GCC:
auto.cpp: In function `int main()`:
auto.cpp:19:20: error: no matching function for call to `append_blah(const char [4])`
   append_blah("nah");
                    ^
auto.cpp:19:20: note: candidate is:
auto.cpp:14:16: note: template<class X> constexpr decltype (plus(x, "blah")) append_blah(X)
 constexpr auto append_blah(X x) -> decltype(plus(x, "blah")) {
                ^
auto.cpp:14:16: note:   template argument deduction/substitution failed:
auto.cpp: In substitution of `template<class X> constexpr decltype (plus(x, "blah")) append_blah(X) [with X = const char*]`:
auto.cpp:19:20:   required from here
auto.cpp:14:59: error: no match for call to `(const plus_f) (const char*&, const char [5])`
 constexpr auto append_blah(X x) -> decltype(plus(x, "blah")) {
                                                           ^
auto.cpp:4:18: note: candidate is:
 constexpr struct plus_f {
                  ^
auto.cpp:6:18: note: template<class X, class Y> constexpr decltype ((declval<X>() + declval<Y>())) plus_f::operator()(X&&, Y&&) const
   constexpr auto operator() (X&& x, Y&& y) const
                  ^
auto.cpp:6:18: note:   template argument deduction/substitution failed:
auto.cpp: In substitution of `template<class X, class Y> constexpr decltype ((declval<X>() + declval<Y>())) plus_f::operator()(X&&, Y&&) const [with X = const char*&; Y = const char (&)[5]]`:
auto.cpp:14:59:   required by substitution of `template<class X> constexpr decltype (plus(x, "blah")) append_blah(X) [with X = const char*]`
auto.cpp:19:20:   required from here
auto.cpp:7:35: error: invalid operands of types `const char*` and `const char [5]` to binary `operator+`
     -> decltype(std::declval<X>() + std::declval<Y>())
                                   ^
GCC feels obligated to tell us why, so in terms of having an accurate, if not in an overly-verbose, error messages, it does its job. It'll take some digging, but a user will eventually be able to find out why it failed. But curiously, clang does no better than std::result_of.
auto.cpp:19:3: error: no matching function for call to `append_blah`
  append_blah("nah");
  ^~~~~~~~~~~
auto.cpp:14:16: note: candidate template ignored:
  substitution failure [with X = const char *]:
    no matching function for call to object of type `const struct plus_f`
constexpr auto append_blah(X x) -> decltype(plus(x, "blah")) {
               ^                            ~~~~
1 error generated.
This doesn't even tell us the types of the arguments to plus_f that caused the failure! If plus_f were a more complicated function with a slight semantic error, we'd be left clueless.

Just for comparison, here's the output with GCC, using auto:
auto.cpp: In instantiation of `constexpr auto plus_f::operator()(X&&, Y&&) const [with X = const char*&; Y = const char (&)[5]]`:
auto.cpp:14:24:   required from `constexpr auto append_blah(X) [with X = const char*]`
auto.cpp:18:20:   required from here
auto.cpp:8:31: error: invalid operands of types `const char*` and `const char [5]` to binary `operator+`
     return std::forward<X>(x) + std::forward<Y>(y);
                               ^
So, when it comes to decltype vs. std::result_of, neither really produced ideal diagnostics and both can be rather unhelpful. decltype at least gives us a little more information, but only with GCC.

I discovered this while working on FU. One of my basic functions that I based the library off of had a very simple bug. Not realizing this, I wrote a small function that called another that called another that eventually landed in that one. When I tried to compile, I got several pages of errors, and they kept suggesting that the problem was in one of the mid-level functions. Assuming I might have gotten the result_of expression wrong, I decided to just use auto and let the compiler figure it out. Then, GCC and clang both told me that the next function in the call tree was the culprit. I continued to mark function by function as returning auto until I found the problem. I had tried to pass an rvalue reference to a function taking a non-const reference. After making it pass by const reference, everything else worked.

Does this mean that we should always prefer auto to result_of or decltype when we don't need SFINAE? I think it should be evaluated on a case-to-case basis. In terms of documentation, auto gives the user a pretty muddy perception on what the function will return. For something like std::plus<>, that's not a problem because addition generally doesn't change the type of its arguments too much. For something simple like std::invoke (C++17), std::result_of_t<F&&(X&&...)> gives us the clearest documentation about how it works--it perfect forwards F and the arguments, X...--but this gives us the worst diagnosis if F can't be called with the arguments. decltype would give the best error message (with clang when the error is shallow, otherwise only with GCC), but decltype(std::forward<F>(f)(std::forward<X>(x)...)) doesn't read as nicely as result_of<F&&(X&&...)>

Whether to use auto, result_of, or decltype is a matter of priorities, weighing the importance of documentation (result_of; maybe enable_if) against semantics (decltype) and diagnostics (auto). For FU, a library that depends heavily on dependent typing, I will probably over time switch entirely to using auto because determining the cause of errors is of great importance for making it usable. Users will likely be confused with messages like "result_of<multary_n_f<1,lassoc_f>(UserFunc, TypeA, TypeB, TypeC)> has no member, `type`". At the same time, this feels like poor style--an unfortunate dilemma. With any hope, GCC and clang will improve how they propagate errors over time.

For information on how to improve the diagnostics of functions using decltype, check out pfultz2's article, "Improving error messages in C++ by transporting substitution failures".

No comments:

Post a Comment

Please feel free to post any comments, concerns, questions, thoughts and ideas. I am perhaps more interested in what you have to say than you are in what I do.