On Wed, Oct 28, 2026 at 2:21 PM Tiago Freire <tmiguelf_at_[hidden]> wrote:
>
> 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.

Uh, I'm guessing you don't mean me, right?

In practice we just Don't Do This. That is, we don't try to
specialize `for_each` in this way.

mfh

>
> ________________________________
> 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_[hidden] <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_[hidden]
> > 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
>