Date: Tue, 27 Oct 2026 22:02:16 +0100
On Tue, 27 Oct 2026, 21:20 Jan Schultke via SG16, <sg16_at_[hidden]>
wrote:
> I would use an algorithm rather than a view. Range goes in, code units
> come out.
>
> Still, I find the use case for views contrived. Why wouldn't you just
> transcode a single time at program boundaries, in which case an algorithm
> is better suited than a view?
>
Any view can be turned into an algorithm by putting it in for_each. An
implementation can then in theory detect that it's a for_each over a
particular view and optimize it.
I have a paper in my head to require that by turning for_each into a
customization point but no time to write it...
It would seem to be the more general solution because that way you can turn
views into algorithms. The flip side isn't true, so it would eventually
require both view and algorithm. It's therefore the superior approach.
>
wrote:
> I would use an algorithm rather than a view. Range goes in, code units
> come out.
>
> Still, I find the use case for views contrived. Why wouldn't you just
> transcode a single time at program boundaries, in which case an algorithm
> is better suited than a view?
>
Any view can be turned into an algorithm by putting it in for_each. An
implementation can then in theory detect that it's a for_each over a
particular view and optimize it.
I have a paper in my head to require that by turning for_each into a
customization point but no time to write it...
It would seem to be the more general solution because that way you can turn
views into algorithms. The flip side isn't true, so it would eventually
require both view and algorithm. It's therefore the superior approach.
>
Received on 2026-10-27 21:02:29
