On Tue, 27 Oct 2026 at 21:05, Tiago Freire <tmiguelf_at_[hidden]> wrote:

> > I also brought up that I don't see why this API needs to be based on
> views. This seems much more intended for transcoding a file or network
> packet once, at the program boundaries, in order to obtain Unicode. Views
> are useful for e.g. temporarily iterating over the code points of a UTF-8
> string, without needing to allocate. > The API being view-based actually
> hurts its usability in my opinion.
>
>
>
> How so? What alternative API would you use?
>

I would use an algorithm rather than a view. Range goes in, code units come
out.

Part of the problem is that if you have views (and notably a distinct type
for each codec), you end up with:

std::u32string decode(std::string_view text, std::codec c) {
    switch (c) {
    case codec::utf8: return decode_with<codec::utf8>(text);
    // 199 more cases ...
    }
}

Where std::codec c is a runtime parameter obtained based on, say, the
contents of <meta charset=...> HTML elements. The paper seems to have
evolved a bit since I made my Mattermost comments and now has some ways to
work with runtime codecs. It was just views last time I saw it, but that
was an early draft.

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?