Re: Boost.Compat

From: Gavin Lambert (boost_at_[hidden])
Date: 2023-05-17 02:11:45

On 17/05/2023 13:44, Vinnie Falco wrote:
> On Tue, May 16, 2023 at 6:37 PM Peter Dimov wrote:
>> It reads the README
> 
> Oh.. wow, that is incredibly restrictive. No public types? Uhhhhh

Technically I think those rules don't preclude making a public 
string_view in your own library that uses a Boost.Compat string_view 
either via private inheritance or composition.

Having said that, I'm not sure that obeys the spirit of the rules, or 
that it's a good idea to proliferate such duplicates even if so; it 
would lead to aggravating type incompatibility (which already exists 
with multiple independent implementations [e.g. optional, shared_ptr, 
and the existing string_view], but is somehow worse when those multiple 
top-level types actually use the same underlying implementation but are 
still otherwise type-incompatible).

Which is probably a good justification for not making a Boost.Compat 
string_view or similar in the first place, although this does limit utility.

It does perhaps beg the question of why the latch couldn't be in a 
detail namespace of Boost.Utility (or Boost.Detail, for that matter) 
instead of a new library instead.  Inevitably *some* user code is going 
to find a Boost.Compat type and start using it directly, README 
notwithstanding.