I don't disagree that you need to check for properly-sized inputs somewhere in the pipeline, the issue is that the definition of "properly-sized" can vary wildly.

Chunking input is a separate concern from correcting endianness, therefore they should be modeled separately (per the Single Responsibility Principle) which is exactly what P4030 does by modeling only endianness correction.

--Robert
________________________________
From: Jan Schultke <janschultke_at_[hidden]>
Sent: Monday, June 22, 2026 06:37
To: Robert A.H. Leahy <rleahy_at_[hidden]>
Cc: sg16_at_[hidden] <sg16_at_[hidden]>; SG9 ranges <sg9_at_[hidden]>; Tom Honermann <tom_at_[hidden]>
Subject: Re: [isocpp-sg16] Thoughts on P4030R0: Endian Views



On Mon, 22 Jun 2026 at 12:14, Robert A.H. Leahy <rleahy_at_[hidden]<mailto: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.