Same goes for things like Phoenix and Proto -- Phoenix allows polymorphic lambdas while Proto allows for doing DSEL building in C++.
I would imagine that if/when C++1x gets polymorphic lambdas and maybe expression template building facilities built in then it's worth deprecating those libraries as well.
I don't think Phoenix is an appropriate example here. The contribution of Phoenix to C++ goes far beyond just simulating polymorphic lambdas or providing a terser syntax for some lambdas. Phoenix allows representing pieces of code as data, which can then be traversed/analyzed/transformed. Adding polymorphic lambdas or nicer lambda syntax to C++1x isn't going to deprecate that use case.
I add two additional notes to help put the discussion in context: - Within the proposed Boost.Local review discussion, several individuals pointed out that they will likely have to work professionally on C++03 compilers for at least a few more years.
I would then think that there's nothing stopping them from using the library even if it's not in Boost.
The name "Boost" carries with it a certain standard of excellence, quality of implementation, and ubiquity. As a result, it is often much more feasible to use a library in a project/team/company if it's part of Boost than if it isn't. Case in point: at my company, we use Boost extensively, but management is very hesitant to introduce a dependency on other libraries, especially if the library "merely" makes coding in general more convenient, rather than providing some domain-specific features or API. I think the situation is similar in many other companies and projects. For this reason, I think libraries whose purpose is to make general-purpose coding more convenient, rather than some domain-specific use, are especially appropriate for inclusion in Boost.
- Recall that Boost has several (recent) libraries that could easily be labelled as "transitional" libraries: Move, Atomic (at least proposed, not sure if accepted), Container. Further, several older libraries are now part of the C++11 standard (e.g., Thread (right?)).
I would think though that these transitional libraries would be deprecated as soon as the standard counterparts become ubiquitous.
Do you consider C++03 as having been ubiquitous for the past 7-10 years? If so, Boost has really been bending over backwards to support compilers that don't support all C++03 features. And that was to support compilers that did not conform to any standard at all! I would expect just as much sympathy and support for compilers which do support a standard (C++03), just not the latest one (C++11), for at least as much time. Regards, Nate