David Ellis
David Ellis
This only covers the Rust runtime's RFC needs. An "FFI" for the JS environment would look completely different, so it should be a different RFC.
While adding something like [CRDTs](https://en.wikipedia.org/wiki/Conflict-free_replicated_data_type) for simultaneously-mutable shared-mutable state is definitely on the table for the future, being able to atomically update any ol' data type is perhaps more useful...
[RFC 012](https://github.com/alantech/alan/blob/main/rfcs/012%20-%20Either%2C%20Option%2C%20and%20Result%20Destructuring.md) outlines a way to automatically unwrap Result/Maybe/Either types within conditionals to eliminate the noise of manual unwrapping that requires a default value if the unwrapping fails. Implementing this...
If you try to import a function that uses a custom type internally that is never exposed through the function inputs/output (or itself uses a function that does), it fails...
Minor issue, but you can't declare a function that takes no input arguments but returns the interface type in an interface. So basically you can't really define basic constructor-function type...
Currently there's some weird inconsistencies in function return type inference *and* explicitly declared return types between multi-line functions and single-line functions. The standard library currently exploits this to get things...
It shouldn't use regex anywhere, as putting `// TODO:` comments in *certain* places in your code can cause compilation issues that are totally unexpected.
If the actual return type of a function doesn't match the return type the user declared, that should be a compiler error.
As discovered during #227 an improper opcode definition can cause the output type to be defined as an interface type. Depending on which opcodes are then used to consume that...
One large issue with the current types is that functions are simply typed `function`, without their argument and return types declared. The compiler will error out usage of higher-order functions...