Oh sure, both. I just wanted the raw byteswap because it is the true
primitive.

BTW, a use case for byteswap that does _not_ have to do with endiness of
your target machine is swapping RGB<=>BGR in image processing. There are
other image processing needs for it that are not endian-of-your-target
machine related. Outside of image processing there is interest these days
in doing linear algebra with 8-bit-sized types (on tiny machines). Certain
convolutions in that space can efficiently use byteswapping. Just because
the use case most common (perhaps) is network I/O - big endian in a world
of little endian machines - doesn't mean that byteswap is useful _only_ for
that.

-- David

On Fri, Feb 26, 2021 at 9:43 AM Matthew Woehlke <mwoehlke.floss_at_[hidden]>
wrote:

> On 26/02/2021 10.48, David Bakin via Std-Discussion wrote:
> > I believe it would be more aligned with the C++ philosophy that this
> newly
> > standardized feature be as fundamental as possible - as close to the
> metal
> > as possible - and thus be a byte-swap proposal and not a
> > "make-it-this-endian" proposal. "make-it-this-endian" is built from two
> > lower level primitives: is_little_endian? and byteswap. To standardize
> > "make-it-this-endian" would leave the use cases needing simply byteswap
> out
> > in the non-standardized cold. And yet it would be easy to _build_
> > "make-it-this-endian" on top of is_little_endian? (now called
> `std::endian`
> > in C++20) and byteswap.
>
> Yes, but given that most uses *are* "make it this endian", it would be
> silly to not have that as well. It's probably best to offer both.
>
> --
> Matthew
>