Re: [boost] [test, parameter, fusion] en/disable_if name clash in trunk

Subject: Re: [boost] [test, parameter, fusion] en/disable_if name clash in trunk
From: Dave Abrahams (dave_at_[hidden])
Date: 2011-12-11 07:55:47

on Sun Dec 11 2011, Tim Blechmann <tim-AT-klingt.org> wrote:

>> >> it seems that the new boost::unit_test::decorator::enable_if,
>
>> >> introduced in
>> >> 
>> >> [1] clashes with boost::enable_if under certain circumstances. this
>> >> currently breaks the boost.heap testsuite (see [2]).
>> >> 
>> >> maybe the test/parameter/fusion maintainers could discuss, how that
>> >> can be resolved?
>> > 
>> > ping
>> > 
>> > the deadline for merging new libraries is in one week. i'd like to merge
>> > boost.heap into the release branch for 1.49, but i won't do it, if the
>> > testsuite does not build, because the enable_if name clash.
>> > 
>> > i have submitted patches to the tracker, but i won't mess with other
>> > people's code.
>> 
>> I haven't answered becase it seems like clearly a Boost.Test issue.  Am
>> I mistaken?  If something needs to be done to Boost.Parameter, you have
>> my blessing to go ahead.
>
> there are boost::enable_if and boost::unit_test::decorator::enable_if, which 
> is pulled into boost::unit_test.
>
> it breaks usage of enable_if because the compiler cannot figure out, which 
> enable_if to use:
>
> namespace boost { namespace mpl {
> template <class T>
> struct lambda<
>     T
>   , typename enable_if<
>         parameter::aux::is_name_tag<T>, parameter::aux::lambda_tag
>     >::type
>
> maybe it is a bug in boost.test, but it can be worked around in 
> boost.parameter and boost.fusion by specifying the full name boost::enable_if.

If it's a bug in Boost.Test, it should be fixed there.  However, if you
can't get Gennadiy to make the fix, go ahead and adjust Boost.Parameter.

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com