Re: [boost] [Proto][Phoenix] Use default transform with SFINAE for expressions?

Subject: Re: [boost] [Proto][Phoenix] Use default transform with SFINAE for expressions?
From: Daniel Walker (daniel.j.walker_at_[hidden])
Date: 2010-09-13 13:03:11

On Sun, Sep 12, 2010 at 10:38 PM, Mathias Gaunard
<mathias.gaunard_at_[hidden]> wrote:
> On 12/09/2010 21:04, Daniel Walker wrote:
>
>> I'm not sure if this could work. The C++0x draft is pretty specific
>> about the context in which substitution failure is allowed, namely,
>> it's only allowed in the immediate context of the function and not as
>> a side effect of instantiating a template (such as a Proto class).
>> Here's the relevant language from 14.8.2.
>
> SFINAE does apply in that kind of context:
>
> template<typename T, typename U>
> decltype(make<T>() + make<U>()) add(T t, U u)
> {
>    return t + u;
> }
>
> The overload is not considered if the expression isn't valid. Of course this
> works with sizeof too, and in C++03 as well (if the compilers supports it).
>
> This is the kind of thing I want Proto's default transform to do.

Actually, I think expression SFINAE may have been a non-standard,
language extension prior to C++0x, or at least, the new standard makes
it explicit. And sorry, I didn't read your previous example closely
enough; surely the error is not a side effect of instantiating
make_mutable, so yes, that kind of context should allow SFINAE.

For what it's worth, your suggestion to convert the return types to be
in template deduction context seems reasonable to me, but I'm afraid
I'm not familiar enough with Proto to give a well informed opinion as
to the trade-offs.

>
>> However, I just checked, and I was pleased to find that gcc 4.5 is now
>> accepting some SFINAE for expressions.
>
> It's been there since 4.4 I think, but has only been working well since 4.5.
> I've put a macro for it in Boost.Config a while ago.

You're right, I checked and gcc 4.4 accepted my example. Thanks!

What I had in mind for the example is to illustrate the feasibility of
a concept checking library that issues substitution failures rather
than compilation errors when a type doesn't model a required concept.
This would provide an API to restrict the compiler such that it
considers only overloads for which the argument types meet the
requirements of the function body. It might be possible to approximate
the functionality of the "requires" keyword from ConceptC++ without
requiring language extensions to C++0x. But this would be a long-term,
general solution. In the mean time, I'm not sure what to do about your
immediate problem.

Daniel Walker