Yeah, I know @Andrew_Trick is also interested in exposing a proper Trivial layout type constraint that could be used in generics as well. That would allow for load and storeBytes to work reliably with unaligned addresses too.
Rather than enter the numeric protocol labyrinth, I would just do this on concrete types. Adding a conformance is simple, and you don’t need to add them all up front; you can just ‘fault’ them in as you need them.
Oh, and btw, despite my example above, I’m not totally comfortable with conforming Int to this protocol. Remember that Int is pointer sized and, conceptually at least, the sending and receiving processes could have different pointer sizes .
Share and Enjoy
Quinn “The Eskimo!” @ DTS @ Apple
 On macOS this can’t happen because 32-bit macOS code runs on the old runtime, and Swift requires the modern runtime.
Any... would be the wrong prefix to use. That tends to be used to signify a type-erased supertype into which you can assign any of the subtypes, which isn't relevant here. The request is for a generic constraint (even if, coincidentally, you could also use it as en existential protocol).
No – AnyObject serves two purposes: as a constraint, and as a type-erased container for any class instance. The Any... part comes from the latter use. That latter use doesn't apply to trivial types, so I am saying it would be inappropriate for the constraint to be AnyTrivial i.e. it should just be Trivial.
While that is typically true, there are other layout constraints which could act as a kind-of "supertype" (or superset, really) of trivial types. For example, compiler also supports exact-size and maximum-size trivial constraints. Would we do AnyTrivial(64)?
Apparently you can use them in @_specialize, and they actually work: