https://isocpp.org/files/papers/D4279R0.html I have formulated my
counter-arguments in this response paper.

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

> Holding values in their "wire" endianness is common practice in every
> codebase I've ever worked on.
>
> You say:
>
> "Why would I be holding a vector of big-endian uint16_t data in the first
> place? There is nothing I can do with this vector except transform its
> endianness so it becomes useful, or shoot myself in the foot by forgetting
> about the endianness of the data inside."
>
> However this overlooks two things:
>
> - There's an additional useful thing you can do with the vector, which is
> write it in the same endianness in which it was sourced
> - Obtaining a wire-endian vector requires no eager work (since the data
> was read that way), unlike eagerly endian swapping it
>

This still doesn't make sense to me. If you don't know whether
reinterpreting the packet's data to uint32_t matches the native endianness,
you can't use the data meaningfully since it's just a bag of bits to you.
However, in that case you don't need endian views at all because you skp
the process entirely; you just reinterpret the bytes as uint32_t.

In any case where you're not just treating the data as a bag of bits, you
need to eagerly convert endianness to make it usable within your program.