It is not clear to me, why print needs to be removed. Isn’t it possible to provide an alternative implementation, that would be “source code compatible” but would refrain from using Any (by taking advantage of pacs+macro combo)?
This is something I think we should really think about as part of the Embedded Swift movement. IMO Rust does this pretty well, with a distinction between std and core, and allowing you to substitute in pieces of std, allowing you then to access more and more abstractions on top of the pieces of std that you've replaced. Implement an allocator? Nice, you get fmt!().
There is a prototype, the images/videos are real, and we plan to add the functionality of the prototype under experimental flags into the compiler soon, so that it's available for early experimental use.
You can send the output to a particular stream. I use it for stderr. Some embedded platforms I’ve worked with had printf that would do nothing unless you provide your implementation. But the program would compile.
Yes, but fixed size Arrays are essentail for precisely those usecases where malloc is missing imo.
It is not clear to me, why print needs to be removed.
There's no intention to remove print(), the vision document just states that we have to provide some alternative implementation (compared to what's in the stdlib today); and your suggestion is one possible option for that, yes.
One interesting intersection is where the artifact bundle definitions of sdks can interplay here. I could imagine that the definition could ferry along information of what type of restrictions are made. E.g. some restricted environments may not have malloc, but others may have full-on concurrency support. Targeting AVR wouldn't be able to have nearly as much available to it as say targeting ESP32-S3/H2.
This may need some alteration linguistically to support additional parameters to #if style guards (or something to that effect). A low level interface to bare metal systems is definitely useful, but it would also be interesting to consider what a more user-welcoming library space would look like too (not just the stdlib).
I see three layers of experiences that could be tackled here: platform engineering (folks bringing in new chips/boards etc), library engineering (folks building out the standard library or other under-pinning libraries for smol swift), and end use engineering (folks building products for that hardware). Each of those audiences have distinct needs, and there likely are tunings that can be focused on each of them.
To be honest - if done well this could be really exciting for many developers - not just large projects but to maker level projects too!
Not necessarily. There are other restrictions we could possibly place on errors that allow them to be propagated without requiring the full expressivity of general existentials. Typed throws might be a good feature in and of itself, but requiring its use in embedded Swift could be a pretty severe dialectization wedge. Our guidance for long-term stable APIs will likely still be to recommend untyped errors to allow for library evolution, and we'd want libraries that intend to target both desktop and embedded Swift to follow that guidance without having to diverge their APIs.
Yup that's the one! In fact if you really really wanted to, you could build a custom stdlib for arm7em with the hermetic seal at link support @kubamracek mentions above, massage it into a swift sdk bundle and use swift package manager to recreate/build that demo.
They've already got some great progress in compiling small code. I believe the implementation is more the subset of the language idea mentioned earlier, but I've used it a little myself and was thoroughly impressed.
It would be great to have their efforts mainstreamed, for sure!
To clarify - this should work with which branch(s) of Swift? I'm getting error: Unknown option '--experimental-lto-mode' when I tried to build an empty package (just to see). Do I need a enableExperimentalFeature setting somewhere?
FWIW I also tried a little mini project and swiftc main.swift -o hello_swift_blink -lto=llvm-full -experimental-hermetic-seal-at-link works fine, but the target, xfrontend, and -static-stdlib all seem dependent on getting the sdk linked first (as would be expected).
swift-driver version: 1.87.1 Apple Swift version 5.9 (swiftlang-126.96.36.199.2 clang-1500.0.40.1)
This is all going to be really nice with the C++ interop...
I have been dreaming about this for quite some time. Next to my iOS and Linux work, I'm doing my development on the ESP (Tensilica + RISCV) family with C(++) – being able to use Swift (and possibly share libraries) there would be heaven.
But not only that, I would imagine that this work would also lead to performance improvements on the desktop systems, so I'm all for it!