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]
<https://eel.is/c++draft/range.as.input.overview>). The standard
specifies a /non-propagating-cache/ ([range.nonprop.cache]
<https://eel.is/c++draft/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.

On 6/7/26 5:29 PM, Eddie Nolan via SG16 wrote:
> 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
> <https://wiki.isocpp.org/2026_Telecons:SG16Teleconference2026-05-27>).
> See also previous discussions on the SG16 reflector
> <https://lists.isocpp.org/sg16/2026/05/4711.php> and mattermost
> <https://chat.isocpp.org/general/pl/6hms7iacbtbmppcyubezerc95a>.
>
> Thanks,
>
> Eddie
>