I was curious what level of ‘soundness’ does Haxe provide for it’s targets, I was reading a discussion in regard to Rust.
I presume some targets are relatively secure due to the underlying target, and generally the GC and extensive type checking provide a lot of security.
To quote one aspect of the article:
“wrap platform functions using an unsafe API, then verify that uses of these functions are conservative. In druid in particular, the druid-shell layer (which abstracts platform capabilities but is not a simple wrapper) has significant amounts of unsafe code, while the druid layer above it (UI logic) has absolutely none. I don’t know of a better way to manage this.”
So for instance does Haxe provide a soundness wrapper over the Lua target ( providing users avoid unsafe casts etc…)?
From a Haxe language perspective it might be ideal if the dox for the api provided details of safety in reference to method and target, but that is likely a huge task. Since Haxe uses an AST analyser it might be possible to do some sanity checks to actually provide safety report - probably not.
It might be good in the light of Rusts approach to highlight generally targets and areas of Haxe that might have less soundness and areas that are considered safe within the Haxe site, a blog post on this could provide some interesting reading to attract users potentially if Haxe does provide a good level of soundness.
It’s a pretty advanced topic and perhaps Haxe is too flexible to provide perfect solutions obviously user libraries can address safety issues, although I do not know of any information relating specifically to Haxe on this topic. But users writing bindings for c++ code I can imagine is quite a risky area. I presume that HL and Cppia are largely soundness, Java because it uses JVM?
Anyway thought I would link to the topic because at the very least it seemed quite interesting and not something I have seen discussed within Haxe specifically although I would imagine many of the unit tests for Haxe are around these areas.