Roadmap

SIMD Types

Possibly a feature that allows functions that do not specify the type (defaults to float) to be compiled as either f32/f64/f32x8/etc... This may or may not be accomplished with generics as a language feature.

Errors

There needs to be functionality for handling errors in a way that does not result in runtime aborts/panics of the whole process.

In debug mode (not implemented), each function call could have a bit of code injected that could early return if there's an error. This could chain all the way up till the rust code is reached and present the error there, without aborting the application.

Another approach that would also work in release mode is requiring fallback behavior, and logging errors to be dealt with by rust code later.

An example of this would be out of bounds array access. If an array is accessed out of bounds, the access is clipped to the array length and 0. Then an error code is logged. Then rust (or maybe Sarus as well) can later react to that logged error.

Memory safety

Need compile time checks that ensure memory is not accessed that is no longer valid. See lifetimes.

Deep Stack

Most data in Sarus is allocated on the stack. However, the amount of memory available on the stack is limited. To enable larger allocations without relying on runtime heap allocations the memory for this operation is allocated at compile time using the deep stack. The deep stack operates similarly to the stack, but is allocated on the heap at compile time. Currently, anything over 4KB is allocated on the deep stack. The deep stack can also be optionally disabled.

There needs to be some compile time static analysis that only interacts with the deep stack frames in functions/scopes where deep stack allocations are made. This is currently resulting in unnecessary code execution where it is not needed.

IR

To perform a some of the compile time checks, it seems that an intermediate representation will be required. The compiler would then do:
Sarus Code -> AST -> IR -> Generate/Modify IR -> Cranelift
This could enable or simplify:

• Compile time codegen
• Alternative backends (llvm)
• Static analysis at IR level for:
  • Lifetime checking
  • Check if function/scope uses deep stack
  • Check if function or loop has continue/early return
  • Incremental compilation may be able to happen at the IR level
• Inlining could be a IR manipulation step

Match

There is currently basic enum (rust-ish style) support, but no match or switch statement. This could be done using something like what Rust has, or something more like Zig or Swift. Either way, there should be something that exhaustively matches over an enum type.