From 708c774ff513c3632ab57da1d1b968cb76b58e0c Mon Sep 17 00:00:00 2001 From: diffuse <48339639+diffuse@users.noreply.github.com> Date: Sat, 28 May 2022 19:53:41 -0400 Subject: [PATCH] Minor language fixes (#364) --- src/destructors.md | 2 +- src/exotic-sizes.md | 4 ++-- src/intro.md | 2 +- src/subtyping.md | 2 +- 4 files changed, 5 insertions(+), 5 deletions(-) diff --git a/src/destructors.md b/src/destructors.md index 3d999613..e70c5e1d 100644 --- a/src/destructors.md +++ b/src/destructors.md @@ -120,7 +120,7 @@ Next variant. In general this works really nicely because you don't need to worry about adding/removing drops when you refactor your data layout. Still there's -certainly many valid usecases for needing to do trickier things with +certainly many valid use cases for needing to do trickier things with destructors. The classic safe solution to overriding recursive drop and allowing moving out diff --git a/src/exotic-sizes.md b/src/exotic-sizes.md index 0c59e2cc..c4a6d240 100644 --- a/src/exotic-sizes.md +++ b/src/exotic-sizes.md @@ -157,9 +157,9 @@ because that wouldn't make sense. We recommend against modelling C's `void*` type with `*const Void`. A lot of people started doing that but quickly ran into trouble because Rust doesn't really have any safety guards against trying to instantiate -empty types with unsafe code, and if you do it, it's Undefined Behaviour. +empty types with unsafe code, and if you do it, it's Undefined Behavior. This was especially problematic because developers had a habit of converting -raw pointers to references and `&Void` is *also* Undefined Behaviour to +raw pointers to references and `&Void` is *also* Undefined Behavior to construct. `*const ()` (or equivalent) works reasonably well for `void*`, and can be made diff --git a/src/intro.md b/src/intro.md index c6ca90f5..4e77ffaf 100644 --- a/src/intro.md +++ b/src/intro.md @@ -32,7 +32,7 @@ Where The Reference exists to detail the syntax and semantics of every part of t The Reference will tell you the syntax and semantics of references, destructors, and unwinding, but it won't tell you how combining them can lead to exception-safety issues, or how to deal with those issues. -It should be noted that we haven't synced The Rustnomicon and The Reference well, so they may have a duplicate content. +It should be noted that we haven't synced The Rustnomicon and The Reference well, so they may have duplicate content. In general, if the two documents disagree, The Reference should be assumed to be correct (it isn't yet considered normative, it's just better maintained). Topics that are within the scope of this book include: the meaning of (un)safety, unsafe primitives provided by the language and standard library, techniques for creating safe abstractions with those unsafe primitives, subtyping and variance, exception-safety (panic/unwind-safety), working with uninitialized memory, type punning, concurrency, interoperating with other languages (FFI), optimization tricks, how constructs lower to compiler/OS/hardware primitives, how to **not** make the memory model people angry, how you're **going** to make the memory model people angry, and more. diff --git a/src/subtyping.md b/src/subtyping.md index c944c1e8..91e870e5 100644 --- a/src/subtyping.md +++ b/src/subtyping.md @@ -75,7 +75,7 @@ this stuff really works, and how we can mess it up. The core problem is that this rule, naively applied, will lead to *meowing Dogs*. That is, we can convince someone that a Dog is actually a Cat. This completely destroys the fabric -of our static type system, making it worse than useless (and leading to Undefined Behaviour). +of our static type system, making it worse than useless (and leading to Undefined Behavior). Here's a simple example of this happening when we apply subtyping in a completely naive "find and replace" way.