You're ignoring the fact that views::from_big_endian_bytes is less generally applicable than views::from_big_endian.

If I have some structure:

struct message {
  std::uint16_t message_type;
  std::array<uint16_t, 5> data;
};

Then views::from_big_endian is a good fit for consuming the wire-endian data array, whereas views::from_big_endian_bytes is not.

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


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.

They are on some level separable; the problem is that there is a cost to the separation, and it's unclear whether we want to encourage everyone paying that cost by default (what is in the standard is automatically the default in a sense).

You can technically compose std::fwrite from std::putchar, but that's not a great motivation for only providing the latter. In fact, it's quite reasonable not to provide the latter at all. In fact, the only way to write to a file descriptor in the WASI is using an fd_write which takes an array of pointers to contiguous buffers, so it can do even more work in one call than std::fwrite.

In short, just because it may be academically satisfying to compose from smaller utilities doesn't mean that it's good engineering. I'd rather only have WASI fd_write() instead of only having putchar(), and I'd rather have views::from_big_endian_bytes instead of views::from_big_endian.