O(1) tuple_element and PCH weirdness

[Douglas Gregor]

On Sep 12, 2007, at 11:57 AM, Paolo Carlini wrote:
> 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?

Looks good to me.

>
> Any clue? If I remember correctly, we should be able to use any c+ 
> +0x new facility without limitations in the headers, right?

Actually, no. Variadic templates can be used without limitations in  
the headers, because variadic templates don't introduce any keywords  
(and they have such a *huge* impact on maintainability).

> 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...

Oh, drat. Now I recall that conversation. Well, we only use  
static_assert in the standard library when in C++0x mode, because  
there was resistance to adding the __static_assert form for use in C+ 
+98 mode. So, we should probably drop __decltype from the compiler  
and only use decltype when in C++0x mode.

That said, I still think the decision not to add the underscored  
versions was a very bad idea. It's going to hamper the adoption of C+ 
+0x and dissuade otherwise-intrepid users from exercising these  
features now. But, I lost that battle quite a while ago.

	- Doug