On Tue, Oct 27, 2026, 16:20 Jan Schultke via SG16 <sg16@lists.isocpp.org> wrote: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.constexpr std::optional<codec> get_encoding(std::string_view label) noexcept;It's the API your web browser uses to read that charset lable right now, as you are reading this.
--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?
SG16 mailing list
SG16@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/sg16
Link to this post: http://lists.isocpp.org/sg16/2026/10/4896.php