Minor language fixes (#364)

pull/367/head
diffuse 3 years ago committed by GitHub
parent 10d40c59a5
commit 708c774ff5
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23

@ -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

@ -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.

@ -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.

Loading…
Cancel
Save