Sounds complicated. Can I suggest setting up a GitHub repo where we can write an implementation, teat it and benchmark it?
I think that looking at a concrete practical example would help in this case.

________________________________
From: SG16 <sg16-bounces_at_[hidden]> on behalf of Mark Hoemmen via SG16 <sg16_at_[hidden]>
Sent: Wednesday, October 28, 2026 9:09:47 PM
To: sg9_at_lists.isocpp.org <sg9_at_[hidden]>
Cc: Mark Hoemmen <mark.hoemmen_at_[hidden]>; sg16_at_[hidden] <sg16_at_[hidden]>
Subject: Re: [isocpp-sg16] [isocpp-sg9] P4246R0 Transcoding Text Views and Ranges for WhatWG and iconv

On Tue, Oct 27, 2026 at 3:02 PM Jonathan Müller via SG9
<sg9_at_[hidden]> wrote:
>
> 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...

This has been a practical problem for us with parallel Ranges. I
wrote a little about this in P3960R0, Section 3.4.

Suppose I want to make `for_each` over
`cartesian_product_view<iota_view, ...>` go fast by using nested for
loops with compiler directives (e.g., OpenACC). I can do that by
specializing `for_each` and adding a nonpublic member to
`cartesian_product_view` to expose its inner views (so I can get the
loop bounds).

Suppose I pipe that `cartesian_product_view` to `transform_view`.
This calls for another `for_each` specialization, this time on
`transform_view<cartesian_product_view<iota_view, ...>, F>`. Suppose
I pipe _that_ to a `zip_transform_view`. The result could be
implemented as nested for loops with compiler directives, but it would
again call for another specialization.

How do I express this kind of pattern-matching with function
specialization? How do I specialize a function on
`A<B<C<D<...<ThingWeWant<...>>>>>>` for an unbounded set of types `A`,
`B`, `C`, `D`, ... with constraints on each type?

I could imagine handling this by specializing views instead, so they
can pass information along to algorithms. For example,
`transform_view<R, F>` might have a specialization for `R =
cartesian_product_view<iota_view, ...>` that knows it's really a
multidimensional loop. But that would couple views to algorithms in
$O(M N)$ fashion.

The Ranges library seems to call instead for views to be "generic"
(not counting range category) and algorithms to express different
iteration patterns. `cartesian_product_view<iota_view, ...>` is just
a range of tuples. Trying to get back the meaning resists Ranges'
design. That's why we find ourselves helping out with P4150
(multidimensional for-each-index). A different language might make
different choices. I'm reminded of what Fortran compilers can do with
array expressions, for example.

mfh

>
> 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.
>
> --
> SG9 mailing list
> SG9_at_lists.isocpp.org
> https://lists.isocpp.org/mailman/listinfo.cgi/sg9
--
SG16 mailing list
SG16_at_[hidden]
https://lists.isocpp.org/mailman/listinfo.cgi/sg16
Link to this post: http://lists.isocpp.org/sg16/2026/10/4923.php