Re: Boost.Compat

From: Gavin Lambert (boost_at_[hidden])
Date: 2023-04-30 23:44:51

On 29/04/2023 02:11, Glen Fernandes wrote:
> On Friday, April 28, 2023, Dominique Devienne wrote:
>> Of course, Boost.Compat (or Boost.Polyfill) would need to turn
>> on/off its std:: alternatives depending on the standard level in use.
>
> If everyone agrees, this can be one of the tenets of Boost.Compat from the
> very beginning.
> 
> The "depending on the standard level in use" might be further clarified to
> mean "provides a fully functional std:: version".

A Boost implementation *must not* provide a definition appearing in the 
std:: namespace.  (Except where expressly permitted by std extension 
points, such as std::hash.  Though those make me sad.)

A Boost implementation *should not* provide a definition that is merely 
`using std::foo` if it does have its own alternative definition, unless 
there is no risk of incompatibility (type traits are relatively safe, 
classes are not).

A Boost implementation *may* provide different implementations depending 
on std level in effect, but *only* in separate namespaces (with alias in 
the "main" namespace).

(i.e. you can define boost::foo::cxx11::myfoo and 
boost::foo::cxx17::myfoo and then alias boost::foo::myfoo to one or the 
other based on std level.  Ideally, a C++17 compilation would define 
both and a C++11 compilation would only define one, since it presumably 
can't define the newer one.)

Where both std and boost types exist, an application should be allowed 
to select whichever one it prefers; including selecting the boost 
implementation of a type even if an equivalent or better type exists in std.

Reasoning: even in this day and age, different compilation units may be 
compiled with different --std levels, and it is a Very Bad Ideaâ„¢ to have 
different ABI definitions visible to different compilation units, as ODR 
violations are no fun for anyone.  If the above is followed then you'll 
get either working code or a clean link error at the seams, instead of 
more subtle horribleness.

Similarly, an uplevel compilation unit may want to explicitly select a 
Boost type in its interface to a downlevel compilation unit, expecting 
that these will be compatible types.

(In an ideal world, this would apply to any other ABI-affecting 
condition as well; though you can usually ignore platform/compiler-level 
differences not as easily changed as the std level.)