Re: [boost] Versioned namespaces (was Rebooting Boost: Call for Lightning Talks @ CppCon)

Subject: Re: [boost] Versioned namespaces (was Rebooting Boost: Call for Lightning Talks @ CppCon)
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2016-05-22 09:01:41

Le 22/05/2016 à 13:18, Niall Douglas a écrit :
>
> 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!
I believed that minor version should be ABI compatible. I don't see the 
need to use namespaces for minor versions. When do you need to version them?

Why do you need macros here? What is wrong with

namespace lib=boost::lib::v100;

?
>
> 4. Problems fixed:
>
> a) Mixing incompatible versions of individual Boost libraries in the
> same process (or even translation unit) is now safe.
As far as all applications are using a specific version.
I don't think this is a good goal. How different versions interact?
Wouldn't this increase the current interoperability problem between 
boost and the standard library, but now between several boost versions?
>
> 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.
Agreed.
>
> 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;
>
Hmm, if Boost.Filesystem is a conforming implementation of the TS 
Filesystem, it should provide a  a <filesystem> file included in the 
std::experimental::filesystem namespace and then the user wouldn't need 
to do anything at the source level, but at the configuration level.

I would add a section of what problem could be introduced ;-)
Should the versions duplicate the whole code? If not, how this 
duplication is avoided?
How the user can partially specialize a class? inside the versioned or 
not versioned namespace? If we want to allow several version on a 
process, it should be the versioned one.

What is the advantage of inlining the version namespaces if the user 
cannot use it directly?

Best,
Vicente