I don't understand how anything about the problem domain implies that I need to eagerly convert endianness.

In order to use the data I need to convert the endianness, but that doesn't mean that I need to eagerly do so since it's not a given that I will use the data.

Also note that since the functionality we're talking about is presented in the form of a view, and therefore we're in the domain of ranges, nothing about constructing such a pipeline implies that conversion will actually occur. Loading the "wire"-endian data might be lazy in the same way the endianness conversion is.

Note that representing the wire-endian data by its destination type, rather than by bytes, allows for the view pipeline to discover the type implicitly, rather than having to restate it. This technique is also used by the interface of Boost.Endian (i.e. I don't need to explicitly tell boost::endian::big_to_native that it's converting to std::uint16_t because I pass it a big-endian std::uint16_t and it can use template argument deduction to discover this).

I've used Boost.Endian heavily and I've never wished that its interface was in terms of buffers/arrays of raw bytes.

--Robert

________________________________
From: Jan Schultke <janschultke_at_[hidden]>
Sent: Monday, June 22, 2026 05:29
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

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]<mailto: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.