On Tue, Oct 27, 2026, 16:20 Jan Schultke via SG16 <sg16_at_[hidden]>
wrote:

>
>
> 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.
>

constexpr std::optional<codec> get_encoding(std::string_view label)
noexcept;

https://github.com/steve-downey/transcode/blob/main/include%2Fbeman%2Ftranscode%2Flabel.hpp#L21

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_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg16
> Link to this post: http://lists.isocpp.org/sg16/2026/10/4896.php
>