We should have a consistent way of talking about rules to follow vs Actual Unsoundness

[Manishearth]

There are a lot of things which are nice rules to follow, that do not necessarily imply unsoundness. For example, rust-lang/unsafe-code-guidelines#346, rust-lang/unsafe-code-guidelines#77, and rust-lang/unsafe-code-guidelines#395 are some tricky subjects where UCG may rule on something that balances practicality, the preexistence of unsafe code, and the sanctity of the model, to end up with something very subtle. However, from our point of view, we are free to provide stricter (but clean) rules provided we are very clear that the actual thing is not as strict. For example, "just never have &uninit" is a rule that is decent to hold and can be followed, but with the current direction the winds are blowing, there will be many scenarios where that is actually okay, and when auditing code this might be passable.

This doesn't have to do with yet-to-be-ruled UCG issues either, in general we can Postel's law our recommendations where possible.

We should probably:

• Have a separate chapter talking about UCG , Postel's law, and how we plan to talk about this
• Use consistent language when talking about this

We want this book to be practical for the purposes of both writing and auditing code, and being super clear here would be great.