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.