Re: [boost] [serialization] Proposal: make 'version' trait(andothers)enable_if-friendly

Subject: Re: [boost] [serialization] Proposal: make 'version' trait(andothers)enable_if-friendly
From: Jeffrey Lee Hellrung, Jr. (jeffrey.hellrung_at_[hidden])
Date: 2012-12-07 00:50:48

On Thu, Dec 6, 2012 at 3:13 PM, Robert Ramey <ramey_at_[hidden]> wrote:

> Jeffrey Lee Hellrung, Jr. wrote:
> > T is not in a deduced context, i.e., the compiler cannot deduce what
> > T is. You can try it yourself if you don't believe me :)
>
> I confess I still don't get it.  Seems to me to be a special instance
> of partial template specialization.

Nathan gave a very nice explanation for why it doesn't work.

Anyway
>
> The following example works on both MSVC 9.0 and GCC 4.5.3
>
> template<class T>
> struct trait {
> };
>
> template<>
> struct trait<int> {
> };
>
> template<class T>
>   struct outer {
>     struct inner {
>     };
> };
>
> template<class T>
> struct indirect : public outer<T>::inner {
> };
>
> template<class U>
> struct trait< indirect<U> > {
> };
>
> without the indirect it did indeed fail on both compilers.

> I would seem to me that a variation on the above above could be
> adapted to give the original poster
>

I don't see how this helps specializing trait< outer<T>::inner >. How would
you arrange to always invoke the trait on this derived indirect type? Where
does indirect come from, anyway? The user, the provider of the trait,
someone else?

In any case, the fact that this technique is used in several other Boost
libraries is a hint that there is no generally applicable workaround, and
even case-specific workarounds (such as something like above) would almost
surely be more onerous than just adding a defaulted Enable type template
parameter to the trait for the sole purpose of enabling SFINAE to address
this use case.

- Jeff