Re: [boost] C++11 decltype/SFINAE puzzler

Subject: Re: [boost] C++11 decltype/SFINAE puzzler
From: Eric Niebler (eric_at_[hidden])
Date: 2012-08-10 18:58:09

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