I believe that Nico says that, in one of his books (I think C++ Templates?),
he and his coauthors are suggesting essentially this variation (but for a
different type, void_t):

#ifndef __cpp_lib_byte
  namespace std { enum class byte : unsigned char { }; }
#endif
// now just write in a modern style per the latest standard
alignas(T) std::byte rawbytes[sizeof(T)];

Nonconforming? Absolutely.
Works in practice? Probably.
Recommended in print by committee members (for a different type but same
structure)? Yes, apparently.

So I would think this variation should also be mentioned, possibly with a
note about the group's opinion of it.


Furthermore, since we usually are in the business of standardizing things
that users otherwise have to write many times themselves: Has SG10
considered actively defining a <std-forward-compat> header library that does
the above for all the things it can, the idea being that users who have to
target multiple implementations at various stages of conformance can include
<std-forward-compat> after all their standard library's own headers and
write their code more closely against the actual latest IS's std:: library,
without having to reinvent the above by hand (incompatibly on different
systems), as a transition tool to help encourage people to adopt the latest
standard?

Nico, do you think that would be use, and if that were available would you
recommend it?



> -----Original Message-----
> From: features-bounces_at_[hidden] [mailto:features-bounces_at_open-
> std.org] On Behalf Of Jonathan Wakely
> Sent: Friday, October 20, 2017 10:47 AM
> To: features_at_[hidden] (features_at_[hidden])
> <features_at_[hidden]>
> Subject: [SG10] Example for __cpp_lib_byte
>
> Would something like this be suitable?
>
> #if __cpp_lib_byte >= 201603
> using byte_type = std::byte;
> #else
> using byte_type = unsigned char;
> #endif
> alignas(T) byte_type rawbytes[sizeof(T)];
> // ...
>
> Both forms will work, but the std::byte version might be preferred to
ensure
> that no arithmetic operations are accidentally performed on the values.
The
> desired type-safety would only be enforced on implementations that
> support std::byte, but if the rest of the code is the same you can be
fairly
> confident there's no arithmetic even when the type is unsigned char.
> _______________________________________________
> Features mailing list
> Features_at_[hidden]
> http://www.open-std.org/mailman/listinfo/features