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.
And haxe has several ways of doing ffi/extern, which then give you the unsoundness of the target, so if c++ you could have many UB.
It’s not that different than the situation in rust, which has also lots of ways to do UB, but the big difference is that haxe doesn’t have, and so doesn’t require, an unsafe keyword.
There’s untyped but it’s not the same, and isn’t required on any of the things I mentioned.
So you have no way to know if you are doing sound or unsound haxe code.
Also most of that in rust is because of the borrow checker which haxe, and 99.99% of others, don’t have.
Reflect is slow I found it useful for use with Flash ( like when talking between loaded swf’s ) and I used it in some of my first haxe ( facebridgehx ) loads, but not used Relfect directly for quite a few years. I know that it can be found in some libraries for instance often tweening libraries eg: https://github.com/jgranick/actuate/blob/master/src/motion/Actuate.hx#L326
I expect it’s used a lot in many of the toolkits when related to asset management. Is there compiler Type/Reflect implementation using macros that avoids the risks of Reflect as in many instance it does not REALLY need to be dynamic?
This library implements a few features for writing Haxe code which generates less null pointer errors. These features are: static extensions for more enjoyable null safety, safe navigation operator, safe arrays, safe api (automatic checks of method arguments for null ).
It reduce null pointer errors, which helps reducing runtime errors, but doesn’t cover any undefined behavior no.
I’m not aware of haxe having anything like this built-in, but it does sound like an intriguing idea since I like both haxe and rust. I think there are limitations in terms of what sort of things you can guarantee since even if you know your target, there could be differences in implementations, etc. Haxe is able to support a number of targets because it doesn’t get bogged down with the compiler having to know how the target compilers and interpreters work internally.
What you can do is make your own macros to enforce rules (warn or error when certain conditions are met). The macros don’t have access to information about the target but if you’re, say, making one for a given language you can add some information yourself. It doesn’t know for example if a given operation mutates data, but you can figure out if a variable is being set more than once.
