[v3] std::tr1::array

[Benjamin Kosnik]

I'm still interested in simple, sniff tests that explain uglification.
If only because we need it now. However, followups on that topic deserve
a new subject, I think (Please?).

>I'm going to toss out an alternative suggestion: let's not uglify the
>TR1 components.

HOORAY! Me likey this answer.

Does that modify the namespace question (__gnu_tr1 vs. __gnu_cxx) in
Jonathan's original question. Ie, should we put extensions directly in
std::tr1?

>First: uglification isn't really a service to the user.  It's a service to
>strict standard conformance.  We need it to pass conformance test
>suites, and not really for any other reason.  Since nothing in TR1 is
>normative, and there are no strict conformance test suites for TR1,
>this isn't an issue.  This is all an extension anyway.

Agreed.

>Second: when and if this stuff goes into the standard, we'll have
>had time to use a better mechanism.  Bjarne is working on some
>preprocessor extensions that will keep user macros from interfering
>with standard headers, and that's a better solution than uglification.
>I expect that something like the #scope directive will make it into
>C++0x (Bjarne usually gets what he wants), but even if it doesn't
>we can implement it as a GCC extension.

I can only hope. I think two-phase lookup actually solved some of the
original issues that were trying to be addressed anyway. If #scope works
on the remaining bits, well then. Sign me up!

-benjamin