Please consider this a "pre-pitch" (aka Daniel's longer-than-a-tweet).
I think Swift should have "bytes literals", supported by the compiler, as well as the standard library. Both
'\x68\x65\x6C\x6C\x6F' would be valid bytes literals, representing the same value.
What is a byte literal?
They are similar to literals for strings/integers/bools. The standard library would provide similar treatment as for other literals. Specifically:
- Byte - Signless 8-bit value, not an int but has bit-twiddling facilities
- Bytes - Collection of bytes with continuous storage: random access, range replaceable, etc.
- ExpressibleByBytesLiteral, BytesLiteralType
Swift should have first-class support for working with binary data. One could argue
[UInt8] works just fine. But the signedness of 8-bit ints leaves a lot to be desired. Also,
Array might not be the right low-level "bag-o-bits" container.
Bytes literal lets us embed binary data in programs. One of the cool features I want Swift to have in the future is something like Rust's include_bytes, which lets you specify a file path and the compiler will expand the source to include the file's content (like an image!). First-class language support makes it possible (I think embedding a array literal that represent
[UInt8] would be...fine, if we don't get first-class bytes). In general, Swift users use
Foundation.Data a lot. With
Bytes, the stdlib would have a low-level support for this need. Having this collection-of-byte in the standard library helps with things like SR-920 as well:
Bytes could back the improved
IntegerLiteralType in the future; it could even be the public interface for literals of arbitrary precision. Signless bytes might even help represent "C strings", if we were to be bold.
A lot of stuff here. I want to gauge interests for this direction from the community with this post before committing to a pitch. Would Swift having these features help you? Is
[UInt8] good enough? Counter points?