The "scope" in the title refers to the extent of the code that has to be manually checked for correctness, once `unsafe` is used.
What I am saying is that the scope of `unsafe` is larger than the `unsafe` block itself.
The "scope" in the title refers to the extent of the code that has to be manually checked for correctness, once `unsafe` is used.
What I am saying is that the scope of `unsafe` is larger than the `unsafe` block itself.
-It turns out that the underlying reason for this observation is also a nice illustration for the concept of *semantic types* that comes up in my [work on formalizing Rust]({{ site.baseurl }}{% post_url 2015-10-12-formalizing-rust %}) (or rather, its type system).
+It turns out that the underlying reason for this observation is also a nice illustration for the concept of *semantic types* that comes up in my [work on formalizing Rust]({% post_url 2015-10-12-formalizing-rust %}) (or rather, its type system).
Finally, this discussion will once again lead us to realize that we rely on our type systems to provide much more than just type safety.
**Update (Jan 11th):** Clarified the role of privacy; argued why `evil` is the problem.
Finally, this discussion will once again lead us to realize that we rely on our type systems to provide much more than just type safety.
**Update (Jan 11th):** Clarified the role of privacy; argued why `evil` is the problem.
So, this example clearly shows that to evaluate the safety of types like `Vec`, we have to look at *every single function* provided by that data structure, even if it does not contain any `unsafe` code.
So, this example clearly shows that to evaluate the safety of types like `Vec`, we have to look at *every single function* provided by that data structure, even if it does not contain any `unsafe` code.
Why is it the case that a safe function can break `Vec`?
How can we even say that it is the safe function which is at fault, rather than some piece of `unsafe` code elsewhere in `Vec`?
Why is it the case that a safe function can break `Vec`?
How can we even say that it is the safe function which is at fault, rather than some piece of `unsafe` code elsewhere in `Vec`?
That's why I think it's worth dedicating an entire blog post to this point.
But we are not done yet, we can actually use this observation to learn more about types and type systems.
That's why I think it's worth dedicating an entire blog post to this point.
But we are not done yet, we can actually use this observation to learn more about types and type systems.
For example, a function is semantically well-typed if it *behaves* properly on all valid arguments, independently of how, *syntactically*, the function body has been written down.
The reason for `MyType::evil` being fine, while `Vec::evil` is bad, is that semantically speaking, `Vec` is very different from `MyType` -- even though they look so similar.
For example, a function is semantically well-typed if it *behaves* properly on all valid arguments, independently of how, *syntactically*, the function body has been written down.
The reason for `MyType::evil` being fine, while `Vec::evil` is bad, is that semantically speaking, `Vec` is very different from `MyType` -- even though they look so similar.
The difference between `Vec` and `MyType` is no less significant than the difference between `f32` and `u32`.
It's just that the compiler has been specifically taught about `f32`, while it doesn't know enough about the semantics of `Vec`.
The difference between `Vec` and `MyType` is no less significant than the difference between `f32` and `u32`.
It's just that the compiler has been specifically taught about `f32`, while it doesn't know enough about the semantics of `Vec`.
At this point, you may be slightly worried about the safety of the Rust ecosystem.
I just spent two sections arguing that the Rust compiler actually doesn't know what it is doing when it comes to checking functions that work on `Vec`.
At this point, you may be slightly worried about the safety of the Rust ecosystem.
I just spent two sections arguing that the Rust compiler actually doesn't know what it is doing when it comes to checking functions that work on `Vec`.
To formally establish safety, one would have to literally go over the entire program and prove that it doesn't misuse `Vec`.
The safety promise of Rust would be pretty much useless.
To formally establish safety, one would have to literally go over the entire program and prove that it doesn't misuse `Vec`.
The safety promise of Rust would be pretty much useless.
-This should not be entirely surprising if you read the aforementioned [post about formalizing Rust's type system]({{ site.baseurl }}{% post_url 2015-10-12-formalizing-rust %}), where I already argued that a proof of (syntactic) type safety does not help to justify safety of most Rust programs out there.
+This should not be entirely surprising if you read the aforementioned [post about formalizing Rust's type system]({% post_url 2015-10-12-formalizing-rust %}), where I already argued that a proof of (syntactic) type safety does not help to justify safety of most Rust programs out there.
I am now making a similar point, coming from a different angle.
The fact that Rust programmers *can* use `Vec` and many other types without much care is a property of the type system that is independent of type safety.
I am now making a similar point, coming from a different angle.
The fact that Rust programmers *can* use `Vec` and many other types without much care is a property of the type system that is independent of type safety.
projects / web.git / blobdiff