Considering the existence of a hypothetical “SwiftLED”.
I detest C++ with the waste heat of a thousand WS28xx pixel array running full-white. But Arduinos are great, FastLED is awesome and Apple’s new Swift programming language is pretty nice.
So, just spitballing, what conditions would be necessary for a hypothetical SwiftLED to exist?
• Swift itself would have to be open sourced. That’s apparently on track for the end of the year.
• There would have to be LLVM back ends for Arduino processors. https://github.com/avr-llvm/llvm exists and appears to be maintained and I don’t think ARM support is a problem for llvm (Although maybe on the low end? How different is an M0-M4 to arm64 in ways that matter in this context?)
• There would need to be Swift/Arduino libraries. I suppose what you do is (re-)write all the pinMode/analogRead/interrupt related stuff in Swift (math is already there from the Swift stdlib.) How hard could it be?
• Then there’s a toolchain/dev environment. I suppose make would (have to) do short-term, or maybe you could pervert Xcode to your cause.
• Finally, FastLED. You can call C and asm from Swift easily (google “Objective-C bridging header”), but not C++. I know FastLED relies on C++'s templating features pretty heavily, so I’m guessing that unless Swift eventually supports calling C++ directly it’s going to be a re-write (possibly borrowing FastLED’s asm implementations) rather than a simple wrapper library on top of the C++. In truth a Swift LED manipulation API would probably look different to a C++ one, so you’d want to re-implement the top layer anyhow. Is the separation of the high- and low-level parts of FastLED such that this is feasible?
Am I missing anything/totally nuts?