Some miscellaneous thoughts:
-
I'm glad something is being done about this, because as everyone else has pointed out, working with imported C arrays is a pain.
-
I think the tail padding issue is important enough that "just use tuples" is a bad idea; it will come back to bite someone. (You probably could have guessed this is my opinion.)
-
I don't actually think the type metadata backwards deployment thing would be a huge issue in practice. There are a variety of options, from making these a special kind of struct to carefully tiptoeing around any operations where older runtimes would switch on the metadata type at all. The main thing that makes this okay in my mind is that conformances aren't attached to type metadata except for dynamic lookup. Even if, say, the backwards-deployed Collection conformance can't be written in Swift (or at least not normal Swift) it can absolutely be contrived/handcoded to do something reasonable.
-
If I think about where I've been using fixed-sized arrays in Rust that aren't C interop or interpreting binary data, it's things like the backing for UUIDs (
[u8; 16]), or Curve25519 keys ([u8; 32]), or SHA-256 hashes (also[u8; 32]). But of course you'd want strong types for most of these whenever possible, and they're not (usually) interchangeable, so most of the benefit is when you're using these types with C interop, or interpreting binary data, or checking that your compile-time constants aren't missing a digit. -
EDIT: I'm not convinced that there's enough of a use case for Erik's "great fixed-size array", and I wouldn't want to see Collectiony semantics left out of the "imported from C fixed-size array".