> But also not portable, such that, you probably want
>
> OSX : normalize, compare the sequence of codepoint
> Linux : compare bytes
> Windows : ??? need to be case sensitive , but afaict it doesn't match
> any unicode casing spec...
>
> Reading Niall's mail, I sort of question the whole approach...
>
> I am not sure that "are these two path component the same" can be
> answered portably - and we probably want that operation to be fast.

I really don't think that path_view::compare() should deviate from
path::compare() unless there is a strong rationale.

path::compare() performs a lexicographical string comparison on all
platforms. That's case sensitive, and has no awareness of the filesystem
nor platform convention.

> Might be better to offer a way to extract a u8string a let the user
> apply the comparison they want on that string?

If you want a filesystem::path from a path_view, just call .path().
It'll feed whatever the path_view's source is to filesystem::path, and
you'll get whatever that conversion to native filesystem encoding produces.

As I mentioned earlier, the fastest way for hash, maps etc is to treat
all path_view's as raw for the purposes of mapping and hashing, then
memcmp() is used. But the programmer would need to explicitly opt into
that, otherwise it might be surprising when paths of equal value but
different encoding do not has nor compare equal.

Niall