On Mon, 22 Jun 2026 at 12:14, Robert A.H. Leahy <rleahy_at_[hidden]> wrote:

> "Okay, but Endian Views don't provide this functionality of representing
> as the type rather than as bytes."
>
> I don't understand how you conclude this. The after part of the first Tony
> Table in the paper is:
>
> constexpr vector<uint32_t> utf16be_to_utf32be(
> const vector<uint16_t>& utf16be_data) {
> return utf16be_data
> | views::from_big_endian
> | views::as_char16_t
> | views::to_utf32
> | views::transform(
> [](const char32_t c) {
> return static_cast<uint32_t>(c);
> })
> | views::to_big_endian
> | ranges::to<vector>();
> }
>
> Note that from_big_endian doesn't mention the type because this is
> inferred from the value type of the upstream range (i.e. utf16be_data).
> This is exactly the property I was referring to in Boost.Endian. If the
> endian views accepted raw bytes (under what I understand is the argument
> you're making) then views::from_big_endian would:
>
> - Need to be templated on the destination type (i.e. it would be
> views::from_big_endian<std::uint16_t>), and
>

Yes, and that's phenomenal because it saves the user a lot more work.
Notice how the function you're citing doesn't do the conversion between
bytes at all. The full pipeline is a lot longer.

What you're citing is a function where (arguably) a one-liner use of
views::transform has been replaced with views::from_big_endian. Even if you
think this serialization pipeline makes sense, it would be interesting to
see you argue why we need this views::transform shorthand in the standard.


> - Would need to check for improperly-sized input (i.e. the case where the
> size of the upstream range is odd)
>

You need to do that either way. If you start with byte arrays, you need to
check for properly sized inputs whether you use views::from_big_endian or
views::from_big_endian_bytes somewhere in the pipeline. That's an
unavoidable step.

It's also a good argument against Endian Views because pipelining all the
way from byte array chunking to endian conversion using views means that
every iteration over a uint32_t element, there needs to be a check.

If you do it in bulk without views, you check exactly once if your byte
array is a multiple of four, and then deserialize without any such checks.
Whether the former can be optimized realiably to the latter is not proven.