On Monday, 14 September 2020 14:20:05 PDT Jason McKesson via Std-Proposals
wrote:
> [char.traits.require] lays down the specific requirements for a type
> to conform to in order to be a viable character traits class. It
> specifically deals in language pointers to `char_type`, not to a
> pointer-like object or a type with `pointer_traits` or whatever. It
> deals in `char_type*`s.
>
> So `char_traits::compare` is based on language pointers, not
> `allocator_traits::pointer`. In fact, `c_str` returns a `CharT
> const*`. Given that, you can compare two strings with different
> allocators but the same `CharT` and `CharTraits` types easily.

Hmm... agreed. I hadn't noticed that c_str() and data() return CharT *, not
basic_string::pointer (or, for that matter, basic_string::value_type *, though
thankfully [char.traits.require] requires that they be the same).

> So I don't buy the notion that, even if the allocators use different
> `pointer` types, that the two strings they point to cannot be
> compared.
>
> Basically, if it's possible to compare both by converting them to
> string_views, then it's ought to be equally possible to compare them
> by comparing them directly. A string_view of a string is logically
> equivalent to the string itself, so non-modifying operations on views
> ought to be valid on the strings themselves.

Agreed.

Two basic_strings of the same character type and whose size_type are equality-
comparable should be comparable themselves.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel DPG Cloud Engineering