On Wed, Nov 23, 2011 at 4:27 AM, Jeffrey Lee Hellrung, Jr. <jeffrey.hellrung@gmail.com> wrote:
Within the discussion for the review of the proposed Boost.Local library, Hartmut Kaiser raised a concern that I think should be addressed more broadly by the community, if possible. I quote Hartmut:
Ok. However this raises a more serious question. Should we as the Boost community still encourage solutions and libraries solely for portability with ancient compilers? I'd say no, but YMMV. Boost will be still around 2, 5, or 10 years from now. What's the utility of adding such a _solely_ backwards oriented library from this POV?
Indeed, I ask the community, do such libraries belong in Boost? If so, is the bar for acceptance of such libraries automatically and necessarily higher than libraries that introduce genuinely new capabilities in C++11? If so, what additional criteria must such a library meet?
I have been watching the discussions around the reviews for the proposed Boost.Local library. I would like to weigh in on this issue that seems to be important to address from a non-involved perspective (mostly because I haven't sent in a review for Boost.Local nor would I do that even now). First, I think there's two problems here that we're all trying to solve: 1) C++11 is good but apparently people don't think it's good enough for production yet. There's a temporal dimension to this problem which means it's just a matter of time when compilers support C++11 as the de-facto version of the language that is supported. During this delay though people want to get the features in C++11 approximated in C++03. 2) C++11 doesn't include a feature that some people find may be useful but can be forced onto users (or at least is being tried to make it popular by getting it into Boost) using whatever facilities are available in the language. The categorical dimension here is not tied to time, effort, or anything else but rather the state of the standard. For solutions that address #1, I would say it depends -- if Boost.Move, Boost.Shared_ptr, Boost.Scoped_ptr, etc. get deprecated when C++11 has been made ubiquitous (which I would believe should be the correct way forward) then yes. Boost.Local unfortunately doesn't belong with the grouping of these libraries precisely because it addresses #2 however "semantically equivalent" local functions are to C++11 lambdas. For solutions that address #2, I would say probably if it's done in good taste and follows the traditions of Boost in terms of quality of implementation, quality of execution, and utility of the solution. I'd say though that addressing issues that fall under the #2 category should be implemented as compiler extensions instead of hacks using existing current language features. This is to say that although Boost.Concept_check is there as a good proof of concept for Concepts, it by itself stands as something that shows the utility of the library in the tradition of Boost's quality. 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. Note that neither of these things resort to using macros which are cheap alternatives to people writing it down themselves. So applying my logic to the discussion on Boost.Local, I see it as doing a not-so-good job of doing #1 while falling short in #2. If however it proves that local functions would be a good addition to the language, I would suggest that the library live outside of Boost, get critical mass, and then be proposed as an extension to the language in the form of a proposal for local functions. Although I don't see how local functions are better than C++11 lambdas that are auto-captured to a local variable, maybe other people would like to use local functions as a different syntax.
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.
- 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. Cheers -- Dean Michael Berris http://goo.gl/CKCJX