Hey guys, I haven’t been ignoring this or blocked on it; just silently collecting feedback and reworking stuff. I’ve substantially reworked the introduction to try to make the problems of unsafe code more clear and accessible. <supand adorable
I’ve also completely reworked the first 1/3rd of the the ownership and lifetimes section based on feedback. Probably going to have to start properly sharding the chapters into proper subpages (ownership is up to 5000+ words).
However BTreeMap is implemented using a modest spoonful of Unsafe (most collections are). That means that it is not necessarily trivially true that a bad Ord implementation will make BTreeMap behave safely. Unsafe must be sure not to rely on Ord where safety is at stake,
It is unclear if this surety is compiler enforced or only user enforced though I don't think it matters too much here because this is more defining a hypothetical situation Unsafe would have to fulfil to be useful. How the real Unsafe works I'm expecting will be elaborated upon later.
because Ord is provided by Safe, and memory safety is not Safe's responsibility to uphold. It must be impossible for Safe code to violate memory safety.
But wouldn't it be grand if there was some way for Unsafe to trust some trait contracts somewhere? This is the problem that unsafe traits tackle: by marking the trait itself as unsafe to implement, Unsafe can trust the implementation to be correct (because Unsafe can trust themself).
Immediately it gets weird but I think it's partially because Unsafe is named Unsafe. So, Unsafe is called Unsafe because it's where Unsafety lies but Unsafe is trustworthy because it is human checked. Conversely, Safe isn't trustworthy because it's only compiler checked and not human checked.
Typically the compiler is more consistent so it'd be the trustworthy party. The humans the inconsistent and unreliable party.
Now that I consider though, it seems you're probably trying to continue the thought from the previous paragraph where Safe could throw Unsafe off course and so couldn't be trusted. Then manual Unsafe implementation would be the direct fix. If that is the intent, I missed it the first few reads. Wording is tricky.
Aside from that minor note, I didn't see any problems with section 2.1. Also, the first example in section 2.2 is immensely clarifying towards this type of questioning. It really helps to show how issues with unsafe aren't necessarily because of unsafe but because of everything else around it.
[EDIT] Read through 4.2 and most seems good and interesting.
Book URL is broken. Where is it now?
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.