[swift-evolution] Low-level Swift

Chris Lattner clattner at apple.com
Sat Jan 9 13:16:37 CST 2016

> On Jan 7, 2016, at 12:33 PM, Brent Royal-Gordon via swift-evolution <swift-evolution at swift.org> wrote:
>> - Is it possible to embed raw binary data in Swift? For example, an equivalent of the following C code "const int8_t foo[6] = {0x00,0x11,0x22,0x33,0x44,0x55};"? The simple Swift equivalent, "let foo: [Int8] = [0x0,0x1,0x2,0x3,0x4,0x6];" is obviously wildly different. Being able to embed raw binary data is very important in a low-level environment: for example, you may need to feed specific data to a device for an initialization sequence at a point where you don't have a filesystem available yet.
> The raw binary data equivalent is a tuple. For instance, I believe this will have the exact memory layout you're looking for:
> 	let foo: (Int8, Int8, Int8, Int8, Int8, Int8) = (0x00, 0x11, 0x22, 0x33, 0x44, 0x55)
>> There might be other aspects that I'm overlooking right now, but I think that's enough to start a discussion: is Swift really meant to be a systems programming language?
> I think it's probably more accurate to say that Swift *aspires* to be a systems programming language. It is already fast enough and has low enough overhead, but some of the features needed aren't there yet, and aren't considered a priority over more common use cases like application programming.

Yep, Brent is right here, this is currently an aspirational goal.  Rust and C (as two examples) are currently better than Swift at certain types of system programming tasks.

"Certain types" is key here, because (as with many terms) “system programming language” means different things to different people.  My goal is for [likely a subset of] Swift to eventually scale down to the smallest firmware, boot loaders, and micro-controllers.  At the same time, I think it should be able to be a fantastic kernel/driver programming language, a great compiler implementation language, and many other things that some people consider to be system programming tasks.

There is a bunch of different work that we need to do to make this happen, and it is likely post-Swift 3.  It is my belief that this will all slot into cleanly to the current design, but we’ll have to test that theory when we get there.  Volatile access, inline assembly, careful control over memory allocation and copies, control over struct field layout, and many other things are sure to come up.


More information about the swift-evolution mailing list