Supporting `unsafe` as a keyword?
k-sareen opened this issue · 2 comments
Another one of my favourite Rust-isms is the clear boundary between "safe" and "unsafe" with the use of the unsafe keyword. I think it's quite nice to be able to work with mainly "safe" code throughout the codebase and then, if required, open the escape hatch with an unsafe { } and then dealing with mucky stuff there. If mmtk and JikesRVM have proven anything, it is that you don't always need to be in "unsafe"-land in order to make good, performant systems.
Currently Virgil code sparingly uses unsafe code, with most of the unsafe code being relegated to the runtime such as pointer arithmetic for GC [1], system calls and other things interfacing with the kernel [2], etc. I think this is largely a good thing, that is, most of the unsafe stuff is already separated, but I think it's semantically nice to go: oh I need to do pointer arithmetic here, I should reason about why I think this is "safe" even though it is an inherently "unsafe" operation.
As an aside, is there a reason why Virgil code for handling files uses file descriptors etc. instead of having a nicer file API -- other than lack of time, I guess.
[1]: https://github.com/titzer/virgil/blob/master/rt/gc/SemiSpace.v3#L83-L86
[2]: https://github.com/titzer/virgil/blob/master/rt/x86-64-linux/System.v3#L75-L84
I'm open to designing such a mechanism. One question is what to do with functions/APIs that take Pointer. Technically, the unsafe things being done (like Pointer.atContents, etc) happen in one place, and then an unsafe value is passed through an API. That might imply that functions need an annotation. I'm not sure how to do that with type parameters.
Another way might be to do it file-by-file, either as an annotation at the top, or by forcing the user to specify additional options at the command line. For example, a big bundle of unsafe code is the runtime itself, which is already normally passed in -rt.files=. That would unlock the use of platform-specific features.
I'm open to designing such a mechanism. One question is what to do with functions/APIs that take Pointer. Technically, the unsafe things being done (like Pointer.atContents, etc) happen in one place, and then an unsafe value is passed through an API. That might imply that functions need an annotation. I'm not sure how to do that with type parameters.
Rust accomplishes this in two ways: a function can be annotated as unsafe, so in this case Pointer.atContents will be marked as unsafe; and then if I use Pointer.atContents anywhere in a function I have to use an unsafe-block in order to make the compiler happy, so in this case it'll be unsafe { Pointer.atContents(ptr) }; And while not semantically forced by the compiler or linter, a comment is written above the unsafe-block to explain why the programmer believes the "unsafe" operation is "safe", while for an unsafe function, a /// # Safety rustdoc comment is written to explain when the function should be "safe" to use.