On 5/19/16 2:17 AM, Niall Douglas wrote:
On 17 May 2016 at 19:39, Edward Diener wrote:
But I'll freely admit I have given up on trying to make any substantial changes to Boost. I prototyped as I said I would a Boost-lite transition layer suitable for a clean Boost fork which I'm using in all my own code. Nobody was interested.
Maybe no one was interested because no one knows what you are talking about.
This I think is inaccurate except maybe for your good self personally.
I presented a plan for how to technically transition to a C++ 14 only Boost 2.0 at my C++ Now 2015 presentation:
The talk was well attended, and by much of the more senior Boost community members.
I happened to attend that talk. I'm not sure if I understood it all. But I can definitely say that I found the proposition unconvincing.
I got the impression everyone understood well what was being proposed. Understanding was not the issue. Agreement with forking Boost into a C++ 14 only edition was the issue.
I saw nothing to be gained by this. I still don't. Boost as from day one had the policy that any library submitted should be compatible with the latest C++ standard. Any library author is free to build his library with C++14 only. Given the above, I never understood what you're proposal was (actually is, because I still don't understand it). Was in some sense to deprecate libraries which supported older compilers as well as later ones? How would you enforce this? Was it to remove libraries which support older compilers from the official distribution? What would be the point of that if they still support the most recent version of C++? Was it to fork boost and make C++14 only versions of the current library? Why would making a libraries applicability narrower make anything better? And who would that considerable amount of work? The library author/maintainer? How would for him to do this? As I said the proposal was either not well conceived, not well explained or most likely both. Now if you had proposed something like: I'd like to make and distribute my own boost distribution which includes only those libraries which are C++14 compatible but not compatible with older compilers - you don't need anyone's permission. Just have at at it. It's not a huge task - at least compared to the other tasks we do. Basically it's just means making specialized version of some python script and start advertising. Actually I alluded to some of this during my Boost 2.0 proposals in 2015. My concern was accommodating was addressing the expected future growth of boost. Here are the relevant proposals a) Resolve issues related to modularization and dependency management. Work on this has been on going and making progress but it's slow going as it's a much more difficult proplem than meets the eye. b) Support development of the ability to generate, test and support subsets of the Boost distribution. c) NOW you could easily propose a subset distribution. Here are some ideas i) a distribution which would not include any components which are now supported by the standard library. This would work for those shops which want to pick a canonical implementation and not have multiple versions of the same thing. ii) The Naill distribution - this would include only those libraries which meet the Naill standard for C++14+ purity. It sounds to me that this is what you're proposing. As more and more library authors became convinced of the utility and popularity of restriction their library set to those certified as "Naill pure" and made changes accordingly, this distribution would naturally grow over time. It wouldn't take a lot of work to maintained. iii) Boost recommended distributation - the concensus of what we think most programmers should be using and excluding those things that wouldn't be recommended for new projects. iv) The whole enchilada - what we are generating and testing now - which would not change.
The community *likes* things just the way they are: serving the Boost community, and to hell with the entire C++ community.
I don't think that is anyway accurate characterization of the community - particularly those who have written, maintained libraries and/or infrastructure. I also don't think there is any evidence to support such a characterization. You seem to believe that the lack of support for your proposal supports this characterization. Well, it's also possible that the large majority of those exposed to the proposal just considered it a bad idea.
Boost consists of about 130 different libraries. I venture to guess that there is not a single library author of those 130 different libraries that wouldn't like to see his library used more by the C++ community.
Right - obviously.
But why you think that Boost library authors write only for other Boost library authors rather than for any C++ programmer is something you need to explain in specific terms. Just making that claim does not explain anything.
Agreed.
The C++ 14 only libraries contributed to date are clearly written first for C++ not Boost.
No problem with that - actually, all the libraries have been written for C++.
They are the future we should be proactively encouraging into a new clean ground up redesigned fork of Boost, a
This doesn't follow from any premise so far stated. Such a fork is a very, very, very bad idea as I stated above. It's also unnecessary to achieve what I think you're goals are. (I doubt I share you're goals either - but it doesn't matter. I challange you to implement as I've described above and prove me wrong).
Boost 2.0, instead of corralling them into legacy and outdated packaging, build, design, documentation and idioms out of some misguided desire for serving the legacy Boost usership before that of the wider C++ community.
I don't see this as a coherent view. But it doesn't matter. I believe that the path we're on can lead to the ability to create custom distributions with different focuses. I don't see any conflict. The problem is that creating this "modular boost distribution system" is much much harder than most people realize. The number of people who are willing to suggest how to change something far, far exceeds the number of people willing and able to actually make this happen. Robert Ramey