X3: Simplify lambda_visitor.

[mlang]

If I am not missing something obvious, there is actually no need for
lambda_visitor to be as complicated as it is.

[vtnerd]

Are there tests for the multiple lambda case? The original version leverages the using keyword to bring in the overloads from the parent, so the outtermost instance had all overloads in the same visibility. I think this verison is ambigious with multiple lambdas, but I haven't tested this exact scenario (operators). It should be the same. I don't think its possible to expand the using declaration either here, I tried a couple of ways with clang 3.5. I don't think the C++ language syntax supports commas in this situation.

[djowel]

There's a plan to expand this to an overloads set. So consider this a work in progress. OTOH, perhaps it belongs somewhere else. How is it ambiguous? A test case would be good.

[vtnerd]

I think the patch here would create an ambiguous function call if multiple lambdas were provided, whereas the code on the develop branch won't. The lambda_visitor class would have an operator() defined in multiple of its children so anyone invoking operator() on lambda_visitor would have a compilation error. The stackoverflow article linked above describes the same situation with named functions. The current version on the develop branch should not have this issue due to the recursive using statements.

Also, I said I think because clang 3.5 doesn't complain with operator(), but does complain if the function is given a name. gcc 4.8 complains in both situations. I wouldn't expect a special case for operators, but I haven't looked up the specification (stackoverflow provides a decent overview). Since @K-ballo filed this lovely bug, I'm assuming its still an outstanding issue with Clang.

[djowel]

Ah I see. I should read more carefully. Happens when there's not enough caffeine :)

[K-ballo]

IIUC overloads are declarations with the same name in the same scope, while all the aggregated operator() in the proposed change obviously come from a different scope each. I believe the intended usage of the code to be ill-formed, but compilers disagree (in interesting ways). I'll consult a higher power and get back.

[mlang]

I am sorry for the noise. While this initially looked like a very nice idea, I really should have tested more :-(.

[tomilov]

I am sure here is the answer.