John Maddock wrote:
BTW, if we're looking at a redesign, and potentially a lot of churn in client code, I think I'd like to see at least a mini-review before any change: Boost.Config is so central to everything and the effects of substantive change potentially so damaging if we get wrong, that some extra-special caution is required in this particular case IMO.
This has gone quite a bit further than what I had in mind. I did not intend a redesign or churn in existing client code, but merely (a) for new macros being added to be of the positive variety and (b) to take advantage of the standard feature macros so that our future maintenance work is minimized. Of course for consistency we would probably add positive macros to match our negative ones, but I did not envisage removing the existing macros or necessarily changing any existing code. I can see why one would think, well, if we're to change things, why not change them even more. Perhaps we should. It's just not what I proposed, or propose. To put it in the most succinct terms, my goal was minimization of the necessary diffs required to support a new feature or a new compiler version. Redesigning things from the ground up is rather out of scope.