[NO MERGE] Comments from nostarch on ch 19 #1087

carols10cents · 2017-12-30T21:42:17Z

carols10cents

break

carols10cents · 2017-12-30T21:43:16Z

second-edition/nostarch/chapter19.md

+Closures. However, I'm not convinced that's ideal, so I thought we might
+include a ToC at the top of this chapter in print so the reader can use it as a
+reference when they come across something they can't figure out. What do you
+think? -->


a table of contents should be fine, although wouldn't it be redundant with the table of contents at the beginning of the book? shrug

yeah, i feel the same

carols10cents · 2017-12-30T21:43:56Z

second-edition/nostarch/chapter19.md

-skip this chapter and come back to it once you run into these things in the
-wild; the features we’ll learn to use here are useful in very specific
+about a few things you may run into that last 1% of the time. Feel free to skip
+this chapter and come back to it only when you run into something unknown in


i don't like "only" here, you CAN read this chapter whenever you want

yes, agreed

carols10cents · 2017-12-30T21:48:05Z

second-edition/nostarch/chapter19.md

+
+People are fallible, and mistakes will happen, but by requiring these four
+unsafe operations to be inside blocks annotated with `unsafe`, you’ll know that
+any errors related to memory safety must be within this unsafe block of code.


some unsafe block of code, not any particular one (implied by "this")

carols10cents · 2017-12-30T21:49:26Z

second-edition/nostarch/chapter19.md

-have an immutable raw pointer and a mutable raw pointer, written as `*const T`
-and `*mut T`, respectively. In the context of raw pointers, “immutable” means
-that the pointer can’t be directly assigned to after being dereferenced.
+Way back in Chapter 4, when first learned about references, we also learned


the "we" removed here needs to come back

carols10cents · 2017-12-30T21:50:30Z

second-edition/nostarch/chapter19.md


-Raw pointers are different than references and smart pointers in a few ways.
-Raw pointers:
+Different to references and smart pointers, raw pointers:


different than or different from or differently from or something, this sounds weird to me

I'd use "from"

carols10cents · 2017-12-30T21:52:57Z

second-edition/nostarch/chapter19.md

+- Don't implement any automatic clean-up
+
+<!-- Can you say here what benefits these provide, over smart pointers and
+references, and using the aspects in these bullets? -->


i'm not sure what to say the benefits are aside from opting out of the safety checks because you're trying to do something rust won't let you do

yup, that's basically it

carols10cents · 2017-12-30T21:58:05Z

second-edition/nostarch/chapter19.md

-raw pointers will be valid since we created them directly from references that
-are guaranteed to be valid, but we can’t make that assumption about any raw
+<!--So we create a raw pointer using the dereference operator? Is that the same
+operator? Is it worth touching on why? -->


i don't think it's the dereference operator, i was under the impression that *const and *mut were types? i could be wrong though, i've never actually stopped to think about this

it's not; *const T and *mut T are types. it's true that it uses an asterisk, but that's it.

carols10cents · 2017-12-30T22:00:46Z

second-edition/nostarch/chapter19.md

+
+We’ve created raw pointers by using `as` to cast an immutable and a mutable
+reference into their corresponding raw pointer types: The `*const T` type
+immutable, and `*mut T` is mutable. Because we created them directly from


the mutable/immutable stuff is now redundant because it was moved before the listing; what's left here is ungrammatical

carols10cents · 2017-12-30T22:03:47Z

second-edition/nostarch/chapter19.md

+methods, but they have an extra `unsafe` out front.
+
+<!-- Above -- so what is the difference, when and why would we ever use the
+unsafe function? -->


i feel like the next sentence answers this, not sure why this is unclear? we could also add this sentence from the nomicon:

On functions, unsafe means that users of the function must check that function's documentation to ensure they are using it in a way that maintains the contracts the function requires.

well we do sort of say that below after showing the error message, maybe move that up here

carols10cents · 2017-12-30T22:05:55Z

second-edition/nostarch/chapter19.md


-#### `extern`  Functions for Calling External Code are Unsafe
+#### Using `extern`  Functions to Call External Code


guess we had some extra spaces in this title, will fix

carols10cents

done reviewing

carols10cents · 2017-12-30T23:42:33Z

second-edition/nostarch/chapter19.md

@@ -214,11 +231,11 @@ to use it properly, and we’ve verified that everything is correct.

 #### Creating a Safe Abstraction Over Unsafe Code


on reread, this section feels like it's missing a transition, something like "just because a function contains unsafe code doesn't mean the whole function needs to be marked as unsafe. in fact, wrapping unsafe code in a safe function is a common abstraction. As an example, let's check out a function from the standard library..."

wdyt?

carols10cents · 2017-12-30T23:43:29Z

second-edition/nostarch/chapter19.md

+`split_at_mut`, that requires some unsafe code and explore how we might
+implement it. This safe method is defined on mutable slices: it takes one slice
+and makes it into two by splitting the slice at the index given as an argument.
+This is demonstrated in Listing 19-4:


i would replace the added "this" with "using split_at_mut is demonstrated...."

carols10cents · 2017-12-30T23:44:09Z

second-edition/nostarch/chapter19.md

-like Listing 19-5. For simplicity, we’re implementing `split_at_mut` as a
-function rather than a method, and only for slices of `i32` values rather than
-for a generic type `T`:
+something like Listing 19-5, and will not compile. For simplicity, we’re


going to change "and will not compile" to "which will not compile"

carols10cents · 2017-12-30T23:44:53Z

second-edition/nostarch/chapter19.md

-is less than or equal to the length. The assertion means that if we pass an
-index that’s greater than the length of the slice to split at, the function
-will panic before it attempts to use that index.
+index given as a parameter is within the slice by checking that its less than


carols10cents · 2017-12-30T23:47:18Z

second-edition/nostarch/chapter19.md

+with the type `*mut i32`, which we’ve stored in the variable `ptr`.
+
+We keep the assertion that the `mid` index is within the slice. Then we get to
+the unsasfe code: the `slice::from_raw_parts_mut` takes a raw pointer and a


s/unsasfe/unsafe/

also either "the" before the function name needs to be removed or it needs to say "the slice::from_raw_parts_mut function"

carols10cents · 2017-12-31T01:29:50Z

second-edition/nostarch/chapter19.md


 ```
 let s1: str = "Hello there!";
 let s2: str = "How's it going?";
 ```

+<!-- Why do they need to have the same memory layout? Perhaps I'm not
+understanding fully what is meant by the memory layout, is it worth explaining
+that a little in this section? -->


how much memory to allocate. all types must take up the same amount of space

carols10cents · 2017-12-31T01:30:47Z

second-edition/nostarch/chapter19.md

-rule of dynamically sized types: we must always put values of dynamically sized
-types behind a pointer of some kind.
+`T` is located, a `&str` is *two* values: the address of the `str` and its
+lengty. As such, a `&str` has a size we can know at compile time: it’s two


s/lengty/length/

carols10cents · 2017-12-31T01:38:20Z

second-edition/nostarch/chapter19.md

+in which dynamically sized types are used in Rust; they have an extra bit of
+metadata that stores the size of the dynamic information. This leads us to the
+golden rule of dynamically sized types: we must always put values of
+dynamically sized types behind a pointer of some kind.

 <!-- Note for Carol: `Rc<str>` is only in an accepted RFC right now, check on
 its progress and pull this out if it's not going to be stable by Oct -->


woooo this made it into 1.21.0! rust-lang/rust#42565

carols10cents · 2017-12-31T01:43:12Z

second-edition/nostarch/chapter19.md

-implemented for everything the compiler knows the size of at compile time. In
-addition, Rust implicitly adds a bound on `Sized` to every generic function.
-That is, a generic function definition like this:
+<!-- I think we dropped that one, right? -->


we cut most of it but didnt drop it completely https://github.com/rust-lang/book/blame/master/second-edition/src/ch17-02-trait-objects.md#L395

oh wait we dropped everything talking about Sized

carols10cents · 2017-12-31T01:44:44Z

second-edition/nostarch/chapter19.md

-case ‘f’ not to be confused with the `Fn` closure trait. `fn` is called a
-*function pointer*. The syntax for specifying that a parameter is a function
-pointer is similar to that of closures, as shown in Listing 19-34:
+<!-- Maybe give an example of when we'd want to use this? -->


when you have a named function that you want to use someplace that takes something that implements an Fn trait, maybe move the map(ToString::to_string) example up here?

steveklabnik · 2017-12-31T21:50:43Z

second-edition/nostarch/chapter19.md

+Closures. However, I'm not convinced that's ideal, so I thought we might
+include a ToC at the top of this chapter in print so the reader can use it as a
+reference when they come across something they can't figure out. What do you
+think? -->


yeah, i feel the same

steveklabnik · 2017-12-31T21:50:56Z

second-edition/nostarch/chapter19.md

-skip this chapter and come back to it once you run into these things in the
-wild; the features we’ll learn to use here are useful in very specific
+about a few things you may run into that last 1% of the time. Feel free to skip
+this chapter and come back to it only when you run into something unknown in


yes, agreed

steveklabnik · 2017-12-31T21:51:39Z

second-edition/nostarch/chapter19.md

+Furthermore, `unsafe` does not mean the code inside the block is necessarily
+dangerous or that it will definitely have memory safety problems: the intent is
+that you as the programmer will ensure the code inside an `unsafe` block will
+have valid memory.


"have valid memory" is werid here

changing it to "the code inside an unsafe block will access memory in a valid way.", better?

steveklabnik · 2017-12-31T21:52:26Z

second-edition/nostarch/chapter19.md

+- Don't implement any automatic clean-up
+
+<!-- Can you say here what benefits these provide, over smart pointers and
+references, and using the aspects in these bullets? -->


yup, that's basically it

steveklabnik · 2017-12-31T21:52:32Z

second-edition/nostarch/chapter19.md


-Raw pointers are different than references and smart pointers in a few ways.
-Raw pointers:
+Different to references and smart pointers, raw pointers:


I'd use "from"

steveklabnik · 2017-12-31T21:55:26Z

second-edition/nostarch/chapter19.md

+
+<!-- have we discussed mangling before this? It doesn't ring a bell with me,
+though it may have been in an early chapter that I forgot --- if not could you
+give a quick explanation here? -->


it's fine. i'd rather not get into it either

steveklabnik · 2017-12-31T21:55:38Z

second-edition/nostarch/chapter19.md

+We’ve managed to go this entire book without talking about *global variables*,
+which Rust does support, but which can be problematic with Rust's owmership
+rules: if you have two threads accessing the same mutable global variable, it
+can incur a data race.


yeah i'd say cause

steveklabnik · 2017-12-31T21:56:50Z

second-edition/nostarch/chapter19.md

 choose once what the type of `Item` will be, since there can only be one `impl
 Iterator for Counter`. We don’t have to specify that we want an iterator of
 `u32` values everywhere that we call `next` on `Counter`.

-The benefit of not having to specify generic type parameters when a trait uses


i'm okay with defaulting to cutting things

steveklabnik · 2017-12-31T21:57:32Z

second-edition/nostarch/chapter19.md


-### Supertraits to Use One Trait’s Functionality Within Another Trait
+### Implementing Supertraits to Use One Trait’s Functionality Within Another Trait


agreed on both counts

steveklabnik · 2017-12-31T21:57:56Z

second-edition/nostarch/chapter19.md

+inner type, if we used it directly to restrict the available functionality, for
+example.
+
+New types can also hide internal generic types. For example, we could provide a


its a single word, "newtypes"

carols10cents · 2018-01-03T02:17:18Z

replaced by #1094

[NO MERGE] Comments from nostarch on ch 19

3f8ea2f

carols10cents commented Dec 30, 2017

View reviewed changes

carols10cents commented Dec 31, 2017

View reviewed changes

steveklabnik reviewed Dec 31, 2017

View reviewed changes

carols10cents closed this Jan 3, 2018

carols10cents deleted the nostarch-ch19 branch January 3, 2018 02:17


		#### `extern` Functions for Calling External Code are Unsafe
		#### Using `extern` Functions to Call External Code

		@@ -214,11 +231,11 @@ to use it properly, and we’ve verified that everything is correct.

		#### Creating a Safe Abstraction Over Unsafe Code


		### Supertraits to Use One Trait’s Functionality Within Another Trait
		### Implementing Supertraits to Use One Trait’s Functionality Within Another Trait

[NO MERGE] Comments from nostarch on ch 19 #1087

[NO MERGE] Comments from nostarch on ch 19 #1087

Conversation

carols10cents commented Dec 30, 2017

carols10cents left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

carols10cents Dec 30, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

carols10cents left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

carols10cents commented Jan 3, 2018

carols10cents Dec 30, 2017 •

edited

Loading