[RFC] exports and linkage for TR1

[Benjamin Kosnik]

> In my opinion the issue isn't particularly urgent. In this sense: as you 
> remind elsewhere, we could as well wait a bit more (probably the erase 
> overloads will change in C++0x) and then add exports for the 
> corresponding, more stable C++0x bits in namespace *std* instead of 
> mixing now tr1 and std facilities.

Realistically, I think this is at least a year away, most probably two.
If not now, when? Wait for 4.3 and the macros and interface proposed by
Mark in his message to be approved by the SC? (Any ETA or definitive
statement on that? ) Or are you saying wait for C++0x?

However, waiting is definitely less work for me and others who have to
deal with backwards-compatibility. I'm just trying to pave the way for
more efficient implementations.

I've been pretty conservative about this up until now, and just want to
signal that I no longer feel the need to be so hesitant. I could be
convinced to do this.

> I have similar feelings about the 
> tr1::type_traits issue: instead of using tr1:: names in the 
> implementation of standard facilities, we can as well wait a bit more 
> (see the message from Howard about a few bits still in flux) and then 
> use the C++0x type_traits facilities in std.

Thanks. This seems like a pretty wise choice at the moment.

Looks like these are the "bits still in flux":

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2028.html

http://home.twcny.rr.com/hinnant/cpp_extensions/builtin_traits.html

I also see some random tweaks
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2032.pdf 

In addition, I remember some issues we all had with the placeholder
weirdness in tuple, at least a justification for existence:
http://gcc.gnu.org/ml/libstdc++/2006-09/msg00175.html

Any others?

Hmm. Ok, maybe this isn't as concrete as I was hoping for set-in-stone
exports.

-benjamin