Re: [boost] MSVC9 SFINAE quirks?

Subject: Re: [boost] MSVC9 SFINAE quirks?
From: Steven Watanabe (watanabesj_at_[hidden])
Date: 2009-01-12 19:26:07

AMDG

Simonson, Lucanus J wrote:
> Maybe I shouldn't have used the word literal.  It is a constant looked up by metafunction, of course.
>
> I was talking about different possible implementations for enable_if having different behaviors when compiled in MSVC.  
>
> I don't know, but I would guess that the order of evaluation of template parameters separated by the comma operator is not defined by the standard?
>   

I believe not.

> A syntax error in the instantiation of some_template<T> might lead the compilation to fail before trying to instantiate and_, I don't know.  It seems that this is the case with MSVC some of the time.
>   

The point is that the compiler doesn't know that some_template<T> needs 
to be instantiated
until after it has gone through the SFINAE.  I know that earlier 
versions of msvc would sometimes
instantiate templates too soon, but I don't know

> The boost implementation of enable_if works well with MSVC.  The alternative 1:
>
> template <typename T, tyepname T2>
> struct enable_if_T { typedef T2 type; };
> template <typename T2>
> struct enable_if_T<false_type, T2> {};
>
> does not behave as expected (and as in gcc) when parsed by MSVC.  
>
> The alternative 2:
>
> template <typename T, tyepname T2>
> struct enable_if_T {};
> template <typename T2>
> struct enable_if_T<true_type, T2> { typedef T2 type; };
>
> results in yet another behavior from MSVC, specifically the problem above, whereas alternative 1 resulted in ambiguous function syntax errors in many cases rather than the expected SFINAE overloading semantic.
>
> Boost's implementation of enable_if:
>
> template <typename T, typename T2>
> struct enable_if : enable_if_c<T::value, T2> {};
>
> converts it from a template on type to a template on the constant specified by value.  This seems to impact the order of template instantiation as well as the assumptions MSVC makes about whether SFINAE should apply.
>   

It's really a case of msvc taking SFINAE too far.  If you only have a 
single function template,
you can either get an ICE or bizarre runtime behavior.  At the moment, I 
can't reproduce your
problem, nor can I reproduce the ICE...

> All three work equivalently in gcc (up to the point one would expect them to) from what I can observe.  Is gcc being overly generous about what it allows to compile, or is MSVC falling short of what the standard says it should allow?
>   

There is not doubt that this is an msvc compiler problem. 

> Obviously, I wouldn't have these troubles if I had just used boost::enable_if from the outset, but I don't want to be given a fish, I want to learn to fish.
>   

As far as I can tell the only way to get sane behavior is to put
enable_if at the top level.  In the attached test, if USE_WRAP == 1
there will be either a compile error or an internal placeholder type
will be printed at runtime.  If USE_WRAP == 0, then everything works.
The other flags seem to have no effect.

In Christ,
Steven Watanabe