Re: [boost] New, powerful way to use enable_if in C++0x

Subject: Re: [boost] New, powerful way to use enable_if in C++0x
From: Jeffrey Lee Hellrung, Jr. (jeffrey.hellrung_at_[hidden])
Date: 2011-04-11 14:40:54

On Mon, Apr 11, 2011 at 11:15 AM, Matt Calabrese <rivorus_at_[hidden]> wrote:

> I'm not sure if there is much interest in this or if someone else
> discovered
> this as well, but I realized today that enable_if can be used in a new way
> in C++0x. Traditionally when working with enable_if with function templates
> you invoke it either in the return type or in an additional function
> parameter of the function. Each of these has advantages and disadvantages.
>
> The parameter form has the downside of augmenting the parameter list. The
> most notable problems with this approach are that it can't be used with
> overloaded operators that require a fixed number of arguments, and it can't
> be used after a variadic argument list.
>
> The return type use of enable_if is often preferred since it does not
> involve augmenting the parameter list, meaning that it can be used with
> most
> overloaded operators, but you still can't use it for conversion operations
> and you can't use it all with constructors as they have no explicit return
> type.
>
> However, in C++0x, there is a new way to use enable_if by altering neither
> the function parameter list nor the specification of the return type. It
> can
> be used with operators, constructors, variadic function templates, and even
> overloaded conversion operations (the latter of which was previously
> considered impossible). The way to do it is with C++0x default function
> template parameters.
>
> Rather than try to explain any further in English, the following code
> should
> demonstrate the approach fairly clearly (tested in GCC 4.5.2):
> http://codepaste.net/23yo8o
>
> There is only one drawback that I can think of off of the top of my head --
> you can't refer to the function parameters by name for the enable_if
> condition, whereas in C++0x if you use the return type form of enable_if
> along with the new trailing return type form of function declarations you
> can. I have never personally wanted to do this and I highly doubt that it's
> common so this is likely entirely a non-issue, plus you can always use
> std::declval anyway so you aren't actually losing any high-level
> functionality. Are there any thoughts on this or drawbacks other than what
> I
> mentioned? Should such use be added to the docs as supported behavior in 0x
> compilers?
>

I think the case for conversion operators alone is compelling enough to
warrant this use being mentioned in the Boost.EnableIf docs...

- Jeff