Thank you, Eddie. I appreciate the treatise provided; I think it covers the concerns well.

The lifetime safety concerns could, I think, be addressed by base_code_units() returning (in the case of an input range) a small container (e.g., std::array<char8_t, 4>) by value rather than returning a reference to a cache held in the iterator. Note that the subrange returned need not be mutable (and probably shouldn't be).

I mentioned one concern that wasn't addressed; the propensity for input ranges to be encountered at an increased frequency due to use of range adapters. I don't have a good sense of how often demotion to an input range should be expected going forward. I think it would be helpful to include some discussion or that and/or a list of range adapters that result in such demotion (a search for "iterator_concept denotes input_iterator_tag" and "iterator_category denotes input_iterator_tag" may be helpful). There seems to be some tension in the ranges library regarding support for input ranges and their potential use to avoid overhead (see [range.as.input.overview]). The standard specifies a non-propagating-cache ([range.nonprop.cache]) exposition-only type that looks like it might be relevant too; it is used in the specification for join_view, join_with_view, lazy_split_view, chunk_view (for input ranges), and cache_latest_view. You concluded that the ergonomics of easy access to the underlying code unit sequence is not favored relative to the safety aspects, but I'm yet to be convinced pending more analysis of range adapters.

Tom.

Cross-posting this message to both the SG9 and SG16 mailing lists.

I've uploaded a new draft D2728R14 of my transcoding views paper, which includes a new discussion of the idea of adding a member function to the transcoding iterator to provide the underlying code unit range for the current code point, and my case against doing so, in the "Design Discussion and Alternatives" section.

It can be found here:

https://isocpp.org/files/papers/D2728R14.html#base_code_units

This should address the requests for relevant code examples from the most recent SG16 telecon (2026-05-27). See also previous discussions on the SG16 reflector and mattermost.

Thanks,

Eddie