On Sun, Dec 1, 2019 at 1:25 PM connor horman via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> I am working on a library in C++ that has IO Capabilities, and as part of
> the library, I define a couple of named requirements that types being
> written or read “raw” (IE. w/o using a special encoding function) have to
> satisfy (otherwise the read/write has undefined behaviour, usually because
> it either causes UB straight up, or either leads to UB or an inconsistent
> state). I was wondering if they could be attached to fread/fwrite for the
> same reason.
> The named requirements are defined as follows
> BytesReadable (for fread):
> A type T satisfies bytes readable if T satisfies TriviallyCopyable, and an
> object of type T, and all subobjects of that object:
> * Are neither a const nor volatile objects (note that modifying a
> const-object through a non-const lvalue is UB, and accessing a
> volatile-object through a non-volatile lvalue is UB)
> * Is not a pointer or pointer-to-member (such a pointer being read can’t
> be used whatsoever due to limitations on pointers, and the value would
> unconditionally be an invalid pointer)
> * Has no non-static data members of a reference type (for obvious reasons)
>

Your description is strangely non-parallel-in-construction for pointer
types and reference types. Shouldn't those two kinds of types be treated
identically?

What's wrong with pointer-to-member types? (Be specific. If what you
describe is true of only one platform's ABI, consider whether the
definition of BytesReadable should maybe be different only on that
platform.)

As Lyberta pointed out, you've already admitted platform-specificness into
your framework as soon as you allow `int` to be BytesWritable — an `int`
written memcpy-wise on one platform might come out backwards if read
memcpy-wise on a platform of a different endianness, or might even segfault
if read on a platform with a different sizeof(int).

Should `struct sockaddr_in
<http://students.mimuw.edu.pl/SO/Linux/Kod/include/linux/in.h.html>` be
BytesReadable and BytesWritable? Why or why not?
What about a struct with a single `const char *` field; why or why not?
If you gave two different answers, justify the difference.

Aside from a few types, and types guaranteed by the standard to be empty,
> no types in the standard library would satisfy this concept.
>

So, "no types aside from a few types" would satisfy this concept? Just say
"a few types"! ;)
Off the top of my head, std::byte would be, plus appropriate
specializations of std::complex, std::pair, std::tuple, and std::variant.

I am extremely skeptical that you'll be able to build your notion up into a
complete and correct framework for what-I-call-"persistence." However, if
you do manage to do so, I'll be very interested!
If you have not already done so, please take a look at
https://www.youtube.com/watch?v=SGdfPextuAU&t=63m45s ("Trivially
Relocatable", C++Now 2019), specifically the part I linked there, which has
to do with persistence and why it's a hard problem for C++'s type system to
deal with.

HTH,
–Arthur