Re: [boost] [local] Review

Subject: Re: [boost] [local] Review
From: Jeffrey Lee Hellrung, Jr. (jeffrey.hellrung_at_[hidden])
Date: 2011-11-21 20:03:13

On Mon, Nov 21, 2011 at 8:30 AM, Hartmut Kaiser <hartmut.kaiser_at_[hidden]>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.

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