On 1/26/2018 1:03 PM, John Maddock via Boost wrote:
Of course if we decide to follow Peter's suggestion and make the change, it is, as always, who is going to do the work. It would be ridiculous to lay this all on John. I am volunteering to help if needed, and I imagine Peter would also, so it would be a matter of finding those people with the time to make this happen if we decided to do it.
I think that since this is effectively Config.v2 we're talking about here, and since I have absolutely no time for this anyway, then if it's decided that this is the way forward, it would be better if the maintenance baton were handed on to someone else at this point: BTW this is absolutely not me "chucking my toys out of the pram", just a realistic assessment that I have neither time nor much inclination for this at this time. I would obviously try and provide constructive criticism / help as I can. I'm also frankly amazed that the design has worked as well as it has for so long - there's an awful lot of hard one knowledge encoded in the Config headers, and I hope that can be retained.
I hope you do realize that my own comments are not even remotely a criticism as to how well config has worked or your incredible job at keeping it as good as it has been. Nor do I think, from what I know of config, that the actual design logic of config has to change. But it may be that I am not seeing the many complications that you foresee.
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.
I hear that. I think that is why Peter's suggestion, which may have been considered in general before as an idea, has never seriously been considered in actuality. Getting it right must be perfect, else the rest of Boost will be greatly messed up.
Best, John.