O(1) tuple_element and PCH weirdness

[Paolo Carlini]

Hi Doug,

and thanks for your prompt feedback.
> 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.
Great.
> 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).
I see.
>> 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.
Ok. Then I will just split the implementations, as we are already doing 
for type_traits, for example. It's easy in the infrastructure that you 
suggested. I think longer term that's the way to go anyway for tuple, 
because of the empty-base optimization that likely we want for C++0x (I 
didn't follow the details of that discussion, please correct me if I'm 
wrong)...

Thanks again,
Paolo.