On 21/04/2013 12:09 AM, [email protected] wrote:
I worry that once Rust fixes memory safety it will quickly be time to replace Rust to correct all the other programmer-traps.
Yeah. There are unfortunately always limits and compromises when making a real language. Rust is attacking a very difficult niche so we have to spend a lot of energy on things that are not strictly about safety. But I appreciate your concern.
In Rust (like C) there doesn't appear to be any way to access the processor flags to cheaply detect overflow on machine types
It would be done with some per-platform inline asm (which we support now), or intrinsics, or an attribute on (say) newtyped integral types. Any of these would probably be ok. The attribute form would make it part of the type, so you'd wind up with checks performed on cast boundaries as well as any non-approximated operations.
your "safe integer objects" will likely have poor performance and of course not work with the standard libraries.
I believe any such integration -- inline asm, intrinsics or attribute -- would be similar, performance-wise. Maybe LLVM's scheduler could do a better job with them if it knows more about the instruction (an argument for intrinsics), and if it knows about the type range itself it may eliminate certain branches as dead code, but otherwise inlining should boil off most of the abstractions equivalently.
Integrated ranged types would also be synergistic with memory safety since a function which takes limited-range inputs can sometimes be statically proven memory-safe when it couldn't otherwise be, allowing the boundary check to be hoisted out of functions entirely even across closed-source-library boundaries when their interfaces are range constrained.
Not entirely. There are always limited approximations at work in these things; range checks can only be statically eliminated in some cases when the approximation is tight, otherwise it has to be repeated on each potentially range-violating arithmetic operation.
LLVM does expose range-limited types and, presumably, does some such check-elimination. I'd not be opposed to absorbing this via a well-integrated attribute on integer types.
We've also had some requests for a mechanism to enable overflow checking on _all_ integer types within a given static or dynamic program extent, using attributes. And similar things are going to be desirable wrt. the floating point environment, which is trickier since it's latent in the CPU state rather than the (static) operations performed. Again, I'd be happy to work through developing patches for this and exploring the problem space. It's a set of bugs usually swept under the rug in C.
Overflow is something that ada seems to handle well, but ada doesn't really seem to be in the running for a wide spread next language outside of certain niches.
Agreed. -Graydon _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
