On Fri, Dec 23, 2022 at 12:33 PM John Maddock via Boost
Is someone willing to explain to me why we have Predef and Config? There are probably a couple of people who can explain. I might even be one of them. And this would be easier to explain if the Config documentation was better. Specifically in the area of stating its goal, what it's meant to do, its domain of operation, its reason for existence. Perhaps we are supposed to know everything just from its name? Do we dare ask for someone to volunteer such information be communicated in the documentation? Or do we all just know?
Perhaps we do (or not!)
I see the two libraries as orthogonal: Config answers the question "does the current compiler/platform/std lib have feature X?" without the user needing to know anything about what the current compiler/platform/stdlib actually is. Where as predef provides a unified way to figure out what the current compiler/platform etc really is, and what version it is. This is obviously a brilliant fallback for situations when Config doesn't have a necessary feature test macro ;)
That, indeed, makes some sense. Predef aims to answer the who of it all. While Config aims to answer the what of it all. Did I already know this? Only I will ever know :-)
I should also state, that Config was never really intended to be a library for the end user (though I'm aware that some do use it), indeed we rather discouraged end-user usage. Rather it was a bunch of shared configuration code, dating back to the heady days when there were only a handful of Boost libraries and everyone round here knew everything that was going on in each of them! Arguably it should be long dead by now, though I have to admit that I'm rather pleased it still mostly just plain works, and even the C++20 feature test macros are rather tedious to use in comparison (even though I was rather hoping they would eventually replace it).
That seems to be an eternal story for Boost. People wish for each new version of C++ to replace something in Boost. And each new C++ edition seems to fall short of that wish. Is that a good thing? As it keeps our work relevant. Or is it a bad thing? That we are failing to impact the standard per the ostensibly noble BoostORG goals. Should we reconsider the goals of the Boost C++ Libraries?
So they could be merged, or not. I'm not sure how much it matters either way ;)
Should it matter? Is it important to combine the who, what, where, when of C++ functionality into one library? Hm, not even the standard tries to do that. Should Boost do that? Should a single Boost library do that? -- -- René Ferdinand Rivera Morell -- Don't Assume Anything -- No Supone Nada -- Robot Dreams - http://robot-dreams.net