So it's taken me a few days to think about how to respond to this. I do in fact use assembly as needed. I wouldn't expect Swift to replace assembly. My question is can it replace a C++ layer? a C layer? Which is what I thought I was asking about.
There is real time computing™ and then there is working with things that are inherently time based. There is just frankly physics involved. As everyone here knows, if you want those timing based hardware things to look event based to the rest of your code you have to write the handlers yourself to fake it. Which I can do. Concurrency certainly makes that a lot easier. Thank you for that.
But, using this compiler flag, what percent of the package will even be in Swift at all? How close to the hardware itself should I expect pure Swift code to be operating?
-
Can one (will one be able in the future) inline assembly like one can with C? That was at one point referred to as niche… well this is that niche.
-
Okay maybe not RealTime™, but how tight of a timing? Can we depend on millis? micros? nanos? to be at least somewhat in the ballpark? Not MORE than C or C++ but on par.
-
Is it a good guideline if you can get it done C++ go ahead and give it a shot in Swift or is that more no than yes?
-
Should I engage with Swift like its a bonafide potential C/C++ replacement for working in the embedded space or will that just break my heart
?
I don’t want to know what others have done to get things to work, I’d like to know what the actual language team’s opinion is of how low Swift should be expected to go.