The FAQ reads like a student project. Most C ABIs have the transform for hidden parameters for large objects. Most slightly higher-level languages do heap promotion for large objects but allocate on the stack where safe. The difficult problems for memory safety are all related to aliasing (you can copy everything, but it’s slow. You can allow only unique ownership, but then you can’t implement any interesting data structures [most of the Rust standard library need some unsafe code as a result]). Temporal memory safety is a hard problem because it is intrinsically non-local: references to an object may exist anywhere and the lifetime of an object depends on them. Interesting solutions all involve constraining where those references can exist and trying to do so in a way that doesn’t negatively impact the developer experience. This generally requires some very subtle and complex type system design.
Temporal memory safety is a hard problem because it is intrinsically non-local: references to an object may exist anywhere and the lifetime of an object depends on them. Interesting solutions all involve constraining where those references can exist and trying to do so in a way that doesn’t negatively impact the developer experience. This generally requires some very subtle and complex type system design.
Indeed. I asked them a while ago how they actually solved this problem, but was unable to get a clear response.
The FAQ reads like a student project. Most C ABIs have the transform for hidden parameters for large objects. Most slightly higher-level languages do heap promotion for large objects but allocate on the stack where safe. The difficult problems for memory safety are all related to aliasing (you can copy everything, but it’s slow. You can allow only unique ownership, but then you can’t implement any interesting data structures [most of the Rust standard library need some unsafe code as a result]). Temporal memory safety is a hard problem because it is intrinsically non-local: references to an object may exist anywhere and the lifetime of an object depends on them. Interesting solutions all involve constraining where those references can exist and trying to do so in a way that doesn’t negatively impact the developer experience. This generally requires some very subtle and complex type system design.
They do it wrong, though, cf https://outerproduct.net/boring/2021-05-07_abi-wrong.html
Indeed. I asked them a while ago how they actually solved this problem, but was unable to get a clear response.