Compare commits

...

4 Commits

Author SHA1 Message Date
Fangyi Zhou
5bb9333ae9 Add i32/u32 suffix for numeric literals in 04_traits/01_trait (#20)
Without an explicit suffix, the compiler is able to use the i32
implementation without the need for an u32 implementation.
2024-05-22 11:04:04 +02:00
LukeMathWalker
e5eee2e83c Fix links. 2024-05-22 11:03:19 +02:00
Jae-Won Chung
9bda4eb7e0 Check status field value after patch (#22) 2024-05-22 11:00:51 +02:00
jw013
63d9ed8478 Update 04_scoped_threads.md (#21)
Fix incorrect statement and remove unintended line break.
2024-05-22 11:00:24 +02:00
5 changed files with 13 additions and 12 deletions

View File

@@ -1,6 +1,6 @@
# The `Drop` trait # The `Drop` trait
When we introduced [destructors](../../02_ticket_v1/11_destructor/README.md), When we introduced [destructors](../03_ticket_v1/11_destructor),
we mentioned that the `drop` function: we mentioned that the `drop` function:
1. reclaims the memory occupied by the type (i.e. `std::mem::size_of` bytes) 1. reclaims the memory occupied by the type (i.e. `std::mem::size_of` bytes)

View File

@@ -1,6 +1,6 @@
# Enumerations # Enumerations
Based on the validation logic you wrote [in a previous chapter](../../02_ticket_v1/02_validation), Based on the validation logic you wrote [in a previous chapter](../03_ticket_v1/02_validation),
there are only a few valid statuses for a ticket: `To-Do`, `InProgress` and `Done`. there are only a few valid statuses for a ticket: `To-Do`, `InProgress` and `Done`.
This is not obvious if we look at the `status` field in the `Ticket` struct or at the type of the `status` This is not obvious if we look at the `status` field in the `Ticket` struct or at the type of the `status`
parameter in the `new` method: parameter in the `new` method:

View File

@@ -65,9 +65,9 @@ that `&v` can't be used from our spawned threads since its lifetime isn't
That's not an issue with `std::thread::scope`—you can **safely borrow from the environment**. That's not an issue with `std::thread::scope`—you can **safely borrow from the environment**.
In our example, `v` is created before the spawning points. In our example, `v` is created before the spawning points.
It will only be dropped _after_ `scope` returns. At the same time, It will only be dropped _after_ `scope` returns. At the same time,
all threads spawned inside `scope` are guaranteed `v` is dropped, all threads spawned inside `scope` are guaranteed to finish _before_ `scope` returns,
therefore there is no risk of having dangling references. therefore there is no risk of having dangling references.
The compiler won't complain! The compiler won't complain!

View File

@@ -9,15 +9,15 @@ mod tests {
#[test] #[test]
fn test_u32_is_even() { fn test_u32_is_even() {
assert!(42.is_even()); assert!(42u32.is_even());
assert!(!43.is_even()); assert!(!43u32.is_even());
} }
#[test] #[test]
fn test_i32_is_even() { fn test_i32_is_even() {
assert!(42.is_even()); assert!(42i32.is_even());
assert!(!43.is_even()); assert!(!43i32.is_even());
assert!(0.is_even()); assert!(0i32.is_even());
assert!(!(-1).is_even()); assert!(!(-1i32).is_even());
} }
} }

View File

@@ -26,5 +26,6 @@ fn works() {
client.update(patch).unwrap(); client.update(patch).unwrap();
let ticket = client.get(ticket_id).unwrap().unwrap(); let ticket = client.get(ticket_id).unwrap().unwrap();
assert_eq!(ticket_id, ticket.id); assert_eq!(ticket.id, ticket_id);
assert_eq!(ticket.status, Status::InProgress);
} }