4 ms·
The only situations that _require_ unsafe are FFI (talking with C libs) and bare-metal access (assembler, embedded, drivers, etc.). An interpreter is totally in
by speed_spread 5y ago
The only situations that _require_ unsafe are FFI (talking with C libs) and bare-metal access (assembler, embedded, drivers, etc.). An interpreter is totally in the clear on these subjects and should not have anyone reaching for unsafe.
Of course, unsafe _can_ also be used to implement code that takes shortcuts beyond what the borrow checker may be able to handle. But if you're building an interpreter, speed is probably not a primary concern anyway.
- celeritascelery 5y ago> An interpreter is totally in the clear on these subjects and should not have anyone reaching for unsafe. This is true for a toy interpreter. You don’t “need” unsafe. But anything other then a toy interpreter has many reasons to reach for unsafe: garbage collection, flexstr, object dispatch, tagged pointers, etc. Not to mention the performance gains from using unchecked functions in hot sections of the interpreter loop.
- speed_spread 5y agoThe arbitrary difference between a "toy" and a "tool" is the completeness of the proposed solution. Correctness, ease of use and documentation concerns could come well before execution speed. I agree that writing an interpreter for an existing language (e.g. Python) one would want to match the performance of existing interpreters and thus would need to use the techniques you mention.
- heavyset_go 5y agoI ask because many implementations of interpreters in Rust that I've seen will reach for unsafe for aspects of the systems that might be inefficient or awkward to implement in safe Rust. I'm curious if or where the author felt the need to do the same or not.