On 8/29/19 3:11 PM, Niall Douglas wrote:
>
>> Once again, being blunt here, I can't see why text reencoding needs
>> anything more than span<T> and basic_string_view<T>. Ranges
>> auto-understands both of those. Again, if the design really needs
>> Ranges, it has to be the wrong design.
>>
>>
>> Iterators (and their child, Ranges) have been the backbone of
>> libraries communicating with one another since Stepanov got it right.
>> Hardcoding span/string_view as the communication medium is the
>> fundamentally wrong choice, because it fundamentally excludes a wide
>> range of use cases, including Boost.Text's unencoded_rope, libstdc++'s
>> and SGI's __gnu_cxx::rope<T> storage, gap_buffer implementations,
>> ring_buffer implementations on the network, and more.
> 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.

There will be pressure to improve compile-time performance for use of
ranges. We may very well get new language features in C++23, but if
not, modules solves AllTheProblems (or, more in vogue these days,
all_the_problems), right? :)

Tom.