>> The reason why I really like span<T> for this is because reencoding
>> benefits greatly from pipelining tricks only possible when input is
>> guaranteed contiguous.
>>
>> I also agree that support for discontiguous input (and output) is also
>> very important.
>>
>> But I'd tend to approach this as span-of-spans i.e. scatter-gather
>> buffers with resumability. Or, precisely what LLFIO's read()/write()
>> already implements.
>
> That approach would require reconstructing the outer span(s) whenever
> the input is modified. That doesn't work well for some use cases (e.g.,
> editors with undo buffers). Ranges offer the proper abstraction for
> handling all of this transparently with optimum run-time performance.

I'm actually advocating a low level API, and a high level API. Low level
API works in terms of resumable span<CharT> (just one span, not span of
spans). High level API's job is to generate as-long-as-possible
span<CharT> calls to the low level API, in order to maximise performance.

As I say, I'll return to path_view development after Belfast. I'll see
what sort of low level API I can come up with intended for easier
implementation of the high level API.

Niall