Every Phoenix actor has three `operator=` functions. One is a normal copy assignment, and the other two are for generating lazy assignment functions (one takes a mutable actor, and the other an immutable one). Gcc is selecting the copy assignment in this instance, and Clang is selecting the lazy assignment function. I believe Gcc is correct in this circumstance, because the copy-assignment function is not templated and therefore should take precedence according to the overload resolution rules. So I _think_ this is a bug in Clang.
Thanks for the explanation!
This came up in boost log over a year ago; Joel and I thought it was a bug in Clang at the time. We should've provided them with a minimal example to see their answer (maybe Joel did?) - I will reduce this further and provide it to them unless you feel the need to.
Please go ahead - thanks! If you end up filing a clang bug, could you share the bug number here? By the way, to explain _why_ I'm trying to assign the actor: I'm not trying to assign it explicitly, but I'm capturing it by value in a lambda, and this seems to require the assignment operator: #include <string> #include <boost/phoenix/core/argument.hpp> #include <boost/phoenix/function.hpp> struct S { void operator()(std::string, int) const; }; boost::phoenix::function<S> lazy; void foo() { auto func1 = lazy(std::string(), boost::phoenix::placeholders::_1); [func1]{}(); } Thanks, Nate