O(1) tuple_element and PCH weirdness

[Paolo Carlini]

Hi,

I'm away from home for a conference and in some spare time decided to 
look into this small issue. As far as I can see this kind of solution 
should do the job:

  template<int __i, typename... _Elements>
    struct tuple_element<__i, tuple<_Elements...> >
    {
      template<typename _Head, typename... _Tail>
        static _Head
        __tohead(_Tuple_impl<__i, _Head, _Tail...>);

      static tuple<_Elements...> __maketuple();

      typedef decltype(__tohead(__maketuple())) type;
    };

What do you think?


Unfortunately, while trying to minimally test it, I noticed that 
something weird is happening with the PCH, at least on powerpc-darwin:

In file included from 
/Users/powerbook/gcc-head-build/powerpc-apple-darwin8.10.0/libstdc++-v3/include/tr1/tuple:55,
                 from 
/Users/powerbook/gcc-head-build/powerpc-apple-darwin8.10.0/libstdc++-v3/include/tr1/functional:48,
                 from 
/Users/powerbook/gcc-head/gcc/libstdc++-v3/include/precompiled/stdtr1c++.h:53:
/Users/powerbook/gcc-head-build/powerpc-apple-darwin8.10.0/libstdc++-v3/include/tr1_impl/tuple:240: 
error: '__tohead' is not a type
/Users/powerbook/gcc-head-build/powerpc-apple-darwin8.10.0/libstdc++-v3/include/tr1_impl/tuple:240: 
error: expected ';' before 'type'
make[2]: *** [powerpc-apple-darwin8.10.0/bits/stdtr1c++.h.gch/O2g.gch] 
Error 1


Any clue? If I remember correctly, we should be able to use any c++0x 
new facility without limitations in the headers, right? Apparently 
however, only if I add by hand -std=c++0x to the command line the PCH 
builds... Alternately, everything builds if I use __decltype, which 
makes for another weird thing: I see that indeed we are registering in 
lex.c the double score version too, but we are not doing the same for 
static_assert, for example, and if I remember correctly, we decided 
never doing that...

Thanks for any feedback,
Paolo