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.)
