Messages in this thread | | | From | Miguel Ojeda <> | Date | Fri, 16 Apr 2021 19:10:17 +0200 | Subject | Re: [PATCH 00/13] [RFC] Rust support |
| |
On Fri, Apr 16, 2021 at 6:14 PM Willy Tarreau <w@1wt.eu> wrote: > > I'm really afraid by languages which force developers to do this or that. > Many bugs in C come from casts because developers know their use case > better than the compiler's developers, and result in lack of warnings > when the code evolves, leaving pending bugs behind. What is important > in my opinion is to let developers express what they want and report > suspicious constructs, not to force them to dirtily work around rules > that conflict with their use case :-/
I understand your concerns. The idea is that by restricting some patterns (in the safe subset), you gain the ability to guarantee the absence of UB (as long as the `unsafe` code is sound).
But please note that the `unsafe` side is still there, and you can reach out for it when needed.
Thus, if you find yourself in a situation where the safe abstractions are not enough for what you need to convey, you have two options: ideally, you think about how to model that pattern in a way that can be exposed as a safe API so that others can reuse it. And if that is not possible, you reach out for `unsafe` yourself.
Even in those cases where there is no other way around `unsafe`, note that you still have gained something very important: now you have made it explicit in the code that this is needed, and you will have written a `SAFETY` annotation that tells others why your usage is sound (i.e. why it cannot trigger UB).
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.
Of course, UB is only a subset of errors, but it is a major one, and particularly critical for privileged code.
Cheers, Miguel
| |