On Mon, Nov 21, 2011 at 8:30 AM, Hartmut Kaiser <hartmut.kaiser@gmail.com>wrote: [...]
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?
Based on your arguments I'd suggest to make (Non-)Boost.Local available somewhere for other people to use and for you to maintain in the long term. You don't have to have it in Boost just for it to be used and useful for others. What's the point in cluttering Boost with this?
I'm sure, any review manager interested in keeping Boost healthy and alive would agree with me. Adding each and every library which seems to be cool just for the sake of it - without thinking about the long term consequences - hurts Boost. Badly.
But I better shut up on this before I'm going to become wind up too much...
Since this indirectly references myself, I'd like to point out that yes, I agree with your overall sentiment: "Adding each and every library which seems to be cool just for the sake of it [...] hurts Boost."
To answer your initial question, though ("Should we as the Boost community still encourage solutions and libraries solely for portability with ancient compilers?"), I don't know. You seem to acknowledge that the Boost community, at one time, did encourage libraries solely for portability; indeed, Boost.Move comes to mind, and I think Boost.Atomic (just proposed? or also accepted? I forget) fits there as well. And now, presumably with the advancement of C++11 (at least partially) compilers, you don't think we should. Or, perhaps, the added value that Boost.Local provides is significantly less than that for Boost.Move and Boost.Atomic (and whatever else), hence doesn't meet the bar for acceptance given that it's almost entirely a portability solution. Both of those are, I believe, justifiable opinions.
Boost.Move is an infrastructure library needed by Boost itself and Boost.Atomics has no MACRO_BASED_INTERFACE. I might sound inconsistent, but it's probably the combination of all three which trips me off: 'solves no real problem', 'just for the sake of portability', and 'MACROS'.
It's fortunate that the quality of the library under consideration has never really been questioned, and, indeed, it has been emphasized even among those who have voted against inclusion. I will have to go back through all the threads (ugh!), but it thus seems that the two primary arguments against inclusion are "Is this actually solving a real problem?" (together with all the discussion about whether the solution that Boost.Local provides is actually better than existing alternatives) and "Does a library providing a portable interface in C++03 for C++11 features belong in Boost?". Regarding the former issue, it *seems* there's been enough actual use to deem the library sufficiently "useful"; but, again, I will have to review the discussion. I'm now thinking, though, that coming to a consensus on this latter issue (together with any qualifications) is too important for me to make a premature ruling on Boost.Local and risk setting an individual-decided precedent.
Am I making too big a deal out of this? Or do you think this is misguided?
Jeff, I fully trust you will make the right decision, and no, you don't make a big deal out of nothing, IMHO. Regards Hartmut --------------- http://boost-spirit.com http://stellar.cct.lsu.edu