At C++ Now a number of informal meetings showed there to be frustrations with the current ecosystem around the Boost C++ Libraries (to paraphrase a founder of Boost, "Boost is supposed to serve *the entire C++ community; it isn't Boost's goal to serve Boost's community*". Recent and recurrent boost-dev discussions have raised the lack of cmake based tooling; lack of ABI management and the consequent ODR violation when mixing Boost versions in the same process; the anti-social behaviour of Boost towards library end users, new ideas, new blood and the wider C++ community; and the chronic lack of maintenance of up to half the Boost libraries. One question which needs to be answered is whether a clean reboot of Boost from the first principles of proving high quality C++ libraries well suited for use with the latest C++ standard is viable. This new collection of C++ libraries would be started completely from scratch (even if some existing libraries were ported into the new organisation), so ANYTHING is possible. All we need is a critical mass of library developers willing to collaborate on developing a shared infrastructure mutually beneficial to all participants, whether library developer or library end user. To that end of discovering if this critical mass is there, five minute lightning talk topics are requested for CppCon this September on this topic: "What design pattern, practice or idiom should a standards aspiring collection of C++ 14/17 libraries share?" Please keep each talk topic focused on a single design pattern, practice or idiom (see suggested talk format below). Each speaker may submit up to THREE talk topics (not all may be accepted if there are a lack of slots, so please rank them in order of preference). Please send your talk topics to me privately by email, only if sufficient numbers present to fill a session will your name and your talk topic be shared with the CppCon Programme Committee. We'll try to arrange a short panel session at the end so attendees can ask questions of the speakers. After the lightning talk we'll arrange a restaurant so all the speakers and any interested attendees can dine together, followed by a night in a Bellevue bar. If after the dust has settled it is felt there is a critical mass sufficient to reboot a brand shiny new edition of Boost, we'll start development! I should *stress* that it is up to the CppCon Programme Committee whether these lightning talks are approved or not. I'll just copy and paste your proposed talk to the CppCon PC as-is. If insufficient lightning talk topics are received by me to fill a 60 minute session, I'll withdraw this talk proposal from CppCon. Suggested talk format ================ Five minutes is not much time, so here is a suggested lightning talk outline: 1. A current widely practiced library design pattern (show example). 2. The problems it generates for library users or maintainers. 3. Your proposed alternative design pattern (show example). 4. The problems the alternative design pattern fixes. 5. Any mockup, prototype or even live demo (!) of the alternative design pattern in action. Suggested talk themes might be documentation, packaging, distribution, testing, tooling, quality assessment, barriers to entry, governance, strategy, important gaps in the standard libraries, automation and deprecation/removal policies. Here is an example of such a lightning talk: 1. Current design pattern: Library v1.00: namespace boost { namespace lib { void foo(size_t, char); } } User code: boost::lib::foo(100, 'n'); 2. Problem: Library v1.01: namespace boost { namespace lib { void foo(char, size_t); } } User code: boost::lib::foo(100, 'n'); // oh oh! 3. Alternative: Library v1.00: namespace boost { namespace lib { inline namespace v100 { void foo(size_t, char); } } } #define BOOST_LIB_NAMESPACE_V100 boost::lib::v100 Library v1.01: namespace boost { namespace lib { inline namespace v101 { void foo(char, size_t); } } } #define BOOST_LIB_NAMESPACE_V101 boost::lib::v101 User code: // Mount v100 of Boost.Lib into "lib" namespace lib=BOOST_LIB_NAMESPACE_V100; lib::foo(100, 'n'); // ABI stable! No ODR violation possible! 4. Problems fixed: a) Mixing incompatible versions of individual Boost libraries in the same process (or even translation unit) is now safe. b) Libraries can now depend on other libraries without worrying about breaking code which depends on them which uses a different version of the same dependency. This greatly helps reduce change ripple effects. c) Forward compatibility or alternative implementation shims are now very easy to implement e.g. library users can externally configure either Boost.Filesystem or std::experimental::filesystem for your library to use, your code simply refers to _some_ Filesystem TS implementation e.g. namespace filesystem = FILESYSTEM_TS_IMPLEMENTATION; filesystem::path mypath; -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/