[boost] Rebooting Boost: Call for Lightning Talks @ CppCon

Subject: [boost] Rebooting Boost: Call for Lightning Talks @ CppCon
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2016-05-22 07:18:47

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/