On Tue, Nov 5, 2013 at 10:17 AM, Gavin Lambert
On 2/11/2013 22:47, Quoth Andrey Semashev:
There are things not intended for public use and yet useful for multiple libraries. I don't think these components should be made a public part of utility, but making them a private part of it seems ok to me.
If something has proven useful for multiple Boost libraries, why wouldn't it be useful for application code?
Take a look at boost/detail contents. Except one or two headers, I don't see why would someone need those things outside Boost.
The only reason I can think of is simply that whoever wrote it doesn't want to pay the costs of documenting, reviewing, and at least somewhat preserving compatibility between releases -- but without documentation, review, and some kind of cross-release compatibility, why would any Boost library authors want to depend on it either?
All these are not big issues for internal components. The comments are enough documentation and in case of incompatible changes all Boost libraries can be updated relatively easily.
Especially once Boost goes modular and a library author might make potentially breaking changes to some of the common code without even having downloaded some of the other libraries that depend on it (possibly thereby not realising the change was breaking, at least until the testers have cycled).
Modularization makes changes to common components more difficult, I admit. But it doesn't mean these components should be made public.