Flesh out views::as_input section

papers/P2728.md

@@ -1335,10 +1335,21 @@ Some range adaptors downgrade forward ranges into input ranges: these are, to my
 understanding, `views::as_input`, `views::cache_latest`, `views::join`, and
 `views::join_with`.
 
+`[range.as.input.overview]` states, "This is useful to avoid overhead that can be
+necessary to provide support for the operations needed for greater iterator strength."
+This use case is potentially relevant for transcoding views, since the size of the
+iterator may be greater with a stronger iterator category. For example, bidirectional
+transcoding iterators need to store the begin iterator from the underlying range to avoid
+overrunning the beginning when transcoding backwards, but forward iterators don't need it.
+
+But implementing `.base_code_units()` for input views would actually cause
+`views::as_input` to *increase* the transcoding iterator's overhead relative to its
+forward-iterator implementation, because the iterator would need to contain an additional
+code unit cache.
+
 `views::as_input` was introduced by [@P3725R3], "Filter View Extensions for Safer Use,"
-and although it's potentially applicable to other use cases, the reason it was introduced
-was composition with `std::views::filter` in order to avoid pitfalls related to mutating
-through a filter.
+and, rather than avoiding overhead, its main motivation was composition with
+`std::views::filter` in order to avoid pitfalls related to mutating through a filter.
 
 This is potentially relevant to transcoding, in that someone might write a filter-view
 pipeline on characters. Say a user wants to print the UTF-8 code units for all the