Attempt to fix grammatically confusing sentence in this paragraph. #2936
Conversation
It is unclear to me what the original author was TRYING to say here, but this is my best guess. It seems like they were trying to say "you can only access the `i32` via `.lock()`, but the actual result of `.lock()` won't be an `i32` value so Rust's type system ensures you actually acquire a lock before using the `i32` value? But I'm not actually sure.
Co-authored-by: yjhn <54238857+yjhn@users.noreply.github.com>
|
@carols10cents Hi there, is there anything else I could do to help get this change reviewed/merged in? |
|
@darrow-olykos Just wait, I'm working on other chapters right now but will be working on chapter 16 in the next few months. Thanks! |
|
Can do! Good luck and thanks for all the great work ☕️ 😁 |
| @@ -71,8 +71,8 @@ that case, no one would ever be able to get the lock, so we’ve chosen to | |||
|
|
|||
| After we’ve acquired the lock, we can treat the return value, named `num` in | |||
| this case, as a mutable reference to the data inside. The type system ensures | |||
| that we acquire a lock before using the value in `m`: `Mutex<i32>` is not an | |||
| `i32`, so we *must* acquire the lock to be able to use the `i32` value. We | |||
| that we acquire a lock before using the value in `m`: `Mutex<i32>`, because `m` | |||
There was a problem hiding this comment.
Hm, to me, the colon after m and before Mutex<i32> means "because", so I'm not sure how adding "because" makes this clearer? What if this was two separate sentences instead, like:
The type system ensures that we acquire a lock before using the value in
m. The type ofmisMutex<i32>, noti32, so we must calllockto be able to use thei32value.
There was a problem hiding this comment.
@carols10cents Your suggestion appears less ambiguous to me 👍
There was a problem hiding this comment.
@carols10cents I was having trouble as well when I was reading this in the book. I think it might be worth it to replace the ':' with something else (The second sentence that you wrote here seems good to me). It didn't even cross my mind that ':' was not the type annotation in Rust itself.
|
Fixed in ca2056e |
|
Nice @carols10cents ! |
It is unclear to me what the original author was TRYING to say here, but this is my best guess.
It seems like they were trying to say "you can only access the
i32via.lock(), but the actual result of.lock()won't be ani32value so Rust's type system ensures you actually acquire a lock before using thei32value?But I'm not actually sure.