Define what "safe"means #347
Conversation
This matches how we do it in the rest of the book, and is easier to tell apart when editing in a monospace font.
There was a problem hiding this comment.
We consider that "memory safety" is the property of a program that cannot have memory corruption. When we talk about it in the context of C, we break it down in 5 sub-categories:
- bounds safety (being safe against read or write buffer overflows);
- lifetime safety (being safe against using object pointers after the end of the object's lifetime);
- type safety (ensuring that your program does not accidentally write a bit pattern corresponding to type A and read it back as corresponding to type B);
- definite initialization (ensuring that an object has a value before you read from it);
- thread safety (ensuring that data races cannot lead to a violation of any of the other types of safety).
"Bounds safety" is also called "spatial safety" and "lifetime safety" is also called "temporal safety". These are inscrutable names that were coined by some sci-fi dork who wanted to feel like they were manipulating spacetime (and I say this as a sci-fi dork who wishes they manipulated spacetime). Don't use them. I will die on this hill.
I'm saying "in the context of C" because you'll find that these categories overlap and may not have the same relevance in other languages. Definite initialization is just a subdivision of type safety. Thread safety is only a problem for memory safety if you can use it to cause another kind of safety violation: for instance, Java is not thread-safe, but object references are atomic and array accesses are bounds-checked, so data races never escalate to memory corruption. If you squint and tilt your head, you can think of lifetime safety as a subdivision of type safety as well.
In the context of Swift, I think it's permissible for you to prefer different names. With that said, should you try to align to how we talk about it in C and in other security communications, I'd suggest that you use "memory safety" instead of "data safety". I would also consider whether you would prefer "strongly typed" over "type-safe" since type-safe (in the context of memory safety) refers to a runtime property, but that might just be choosing one can of worms over the other, and keeping "type safety" the way you currently use it is not the worst approximation.
| Sometimes you need to work outside of the bounds of safety --- | ||
| for example, because of limitations of the language or standard library --- | ||
| so Swift also provides unsafe versions of some APIs. | ||
| When you use types or methods whose name includes the word "unsafe", |
There was a problem hiding this comment.
This is not the only word that announces unsafety. I know that there's also at least "unchecked" and "unmanaged", and occasionally there is nothing in particular. @glessard can confirm (if you want to elaborate on it).
Fixes: rdar://126308272