On Tue, 27 Oct 2026 at 21:05, Tiago Freire <tmiguelf@hotmail.com> 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?