On 7/6/2012 1:15 PM, Andrew Sutton wrote:
So, my question is: what can be done about this? Can we get the benefit of automatic type deduction in return types without causing SFINAE to drop functions from the overload set? Is there another trick we can use to report errors meaningfully when APIs are misused?
No!
Just kidding. I was actually wondering something very similar earlier today. How can we intelligently document the causes of SFINAE-based overloading errors? I don't have a good answer yet.
I spent some time playing with this today. Attached is my best shot. The basic idea is to change the RETURNS macro to -- in addition to declaring the trailing return type and the function body -- also define an implicit conversion to a function pointer. That gets selected as the function called in the case that sfinae fails. That function returns a sfinae_error that contains some useful information: the text of the expression that failed to compile, the file and line number of the sfinae failure, and the types of the function parameters (mangled, unfortunately). It's used like this: struct S0 { template<typename T> auto operator()(T t) const RETURN( (t), t + 1 ) }; The first macro parameter is the function parameters. The second is the expression to evaluate. If all your function objects are declared this way, you can call them as normal. But if you get a sfinae failure anywhere in the call chain, the result of the call is a sfinae_error object with the goods. Can anybody do better? -- Eric Niebler BoostPro Computing http://www.boostpro.com