[swift-evolution] Low-level Swift

[Goffredo Marocchi]

Hello Chris,

For many, this is also the era of domain specific languages and I think that maybe Swift's aspirational goal of doing everything (scaling from low level device driver code, to rapid prototyping, to graphically rich and versatile application, to embedded devices, etc...) might put a big burden on the language and on the compiler.

Do you see Swift putting more and more emphasis to interoperability with other languages which might have better characteristic at dealing with a specific domain than Swift does currently with maybe also some push to extend those languages to inter operate better and better?

Sent from my iPhone

> On 9 Jan 2016, at 19:16, Chris Lattner via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
>>> 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.
> 
> -Chris
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution