[boost] [boost::endian] Summary of discussion #1

Subject: [boost] [boost::endian] Summary of discussion #1
From: Tomas Puverle (tomas.puverle_at_[hidden])
Date: 2010-06-02 11:37:30

Thank you everyone for your contributions.  It seems the activity is dying down
a little and some consensus has been reached, so I decided to summarize the
thread here for my and other people's benefit.

Unanswered question:
One question which I posed in the original thread and didn't get picked up by
anyone was to do with the metafunction is_mutable_range<T>.  I use it to
determine whether T is a range as opposed to just a value.  I was suggesting
is_mutable_range<> and is_const_range<> could be added to Boost.Range but nobody
had any opinions.

Basic interface:
There were many suggestions for changes/improvements but in the end, it seemed
that the proposed functional interface was generally ok.  Beside the two
functions swap<>() and swap_in_place<>(), there was a desire for two simpler
alternatives, to<>() and from<>(), which would imply the "host" portion, i.e.
swap<host_to_{little/big}>() would be equivalent to to<{little/big}>() and
swap<{little/big}_to_host>() would be equivalent to from<{little/big}>().

The idea of "network" being a synonym for "big" was raised but ultimately
rejected, due to the fact that the library shouldn't be tied to any particular
device/protocol.

Floating point values:
There is a potential issue with swapping floating point values.  This will be
resolved by limiting the contexts in which swap<>, from<> and to<> can be used.

Typed vs untyped:
One of the most contentious issues of the whole thread, I think both sides have
accepted that there is value in the other side's approach (or, at the very
least, I don't see how my library is going to make it through the review unless
I implement it :)
Having said that, as the typed interface ultimately relies on copying of data,
there may have to be some limitations on floating point values.

Bitfields:
There was some desire for generic bit swapping/bit fields.  I have some ideas on
this but for now I would prefer to concentrate on the byte-swapping issues and
revisit this in the future.

This seems like a reasonable plan for implementation.  Thanks again for all the
input.

Tom