On Fri, Apr 16, 2021 at 6:14 PM Willy Tarreau <w@xxxxxx> 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
