On 4/16/21 12:37 PM, Willy Tarreau wrote: > Hi Miguel, > > On Fri, Apr 16, 2021 at 07:10:17PM +0200, Miguel Ojeda wrote: >> And by having the compiler enforce this safe-unsafe split, you can >> review safe code without having to constantly worry about UB; and be >> extra alert when dealing with `unsafe` blocks. > > I do appreciate this safe/unsafe split and a few other things I've seen > in the language. The equivalent I'm using in C is stronger typing and > "const" modifiers wherever possible. Of course it's much more limited, > it's just to explain that I do value this. I just feel like "unsafe" > is the universal response to any question "how would I do this" while > at the same time "safe" is the best selling argument for the language. > As such, I strongly doubt about the real benefits once facing reality > with everything marked unsafe. Except that it will be easier to blame > the person having written the unsafe one-liner instead of writing 60 > cryptic lines doing the functional equivalent using some lesser known > extensions :-/ > It's possible that many of the questions you've been specifically asking about, by sheer coincidence, are targeted towards the problems that would indeed require a lower-level abstraction built within an unsafe block; meaning you've managed to evade the tons of other upper layers that could be written in safe Rust. Indeed, at a certain layer, unsafe is unavoidable for the kind of work that is done in the kernel. The goal is to shrink the unsafe blocks as much as possible and confirm the correctness of those pieces, then build safe abstractions on top of it. For what it's worth, if there was some post-human apocalyptic world where literally everything had to go inside an unsafe block, the silver lining in a hypothetical situation like this is that unsafe does not disable all of Rust's static analysis like the borrow checker, etc. It allows you to do things like directly dereference a pointer, etc. Unsafe also doesn't automatically mean that the code is wrong or that it has memory issues; it just means that the compiler can't guarantee that it doesn't based on what you do in the unsafe block. Connor
