Skip to content

Commit 10a28ca

Browse files
committed
Add exercise involving lifetime elision
1 parent b730882 commit 10a28ca

4 files changed

Lines changed: 127 additions & 0 deletions

File tree

dev/Cargo.toml

Lines changed: 2 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -134,6 +134,8 @@ bin = [
134134
{ name = "lifetimes2_sol", path = "../solutions/16_lifetimes/lifetimes2.rs" },
135135
{ name = "lifetimes3", path = "../exercises/16_lifetimes/lifetimes3.rs" },
136136
{ name = "lifetimes3_sol", path = "../solutions/16_lifetimes/lifetimes3.rs" },
137+
{ name = "lifetimes4", path = "../exercises/16_lifetimes/lifetimes4.rs" },
138+
{ name = "lifetimes4_sol", path = "../solutions/16_lifetimes/lifetimes4.rs" },
137139
{ name = "tests1", path = "../exercises/17_tests/tests1.rs" },
138140
{ name = "tests1_sol", path = "../solutions/17_tests/tests1.rs" },
139141
{ name = "tests2", path = "../exercises/17_tests/tests2.rs" },
Lines changed: 50 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,50 @@
1+
// Sometimes, we have structs which hold on to data temporarily. A use-case of
2+
// this could be a routing component which accepts a connection and returns it to
3+
// another recipient. To avoid copying the data, we just accept a reference with
4+
// lifetime and return this reference later.
5+
//
6+
// In the example below, we create a `Router` instance in a limited scope. It
7+
// accepts a connection reference created in the enclosing scope and returns it.
8+
// In theory, this should be possible given that the connection reference outlives
9+
// the scope from which it is returned. However, the borrow checker does not
10+
// seem to understand it. What can we do about that?
11+
12+
// TODO: Fix the compiler error about `router` not living long enough without changing `main`
13+
14+
struct Router<'a> {
15+
connection: Option<&'a u64>,
16+
}
17+
18+
impl<'a> Router<'a> {
19+
fn new() -> Self {
20+
Self { connection: None }
21+
}
22+
23+
fn accept_connection(&mut self, connection: &'a u64) {
24+
self.connection = Some(connection);
25+
}
26+
27+
fn return_connection(&mut self) -> Option<&u64> {
28+
self.connection.take()
29+
}
30+
}
31+
32+
// Do not change `main`
33+
fn main() {
34+
let connection = &123;
35+
36+
let returned_connection = {
37+
// Create router within scope
38+
let mut router = Router::new();
39+
40+
// Accept connection which lives longer than the router
41+
router.accept_connection(connection);
42+
43+
// Return connection which **should** live longer than the router
44+
router.return_connection()
45+
};
46+
47+
if let Some(connection) = returned_connection {
48+
println!("The connection is {connection}");
49+
}
50+
}

rustlings-macros/info.toml

Lines changed: 15 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -832,6 +832,21 @@ dir = "16_lifetimes"
832832
test = false
833833
hint = """Let the compiler guide you :)"""
834834

835+
[[exercises]]
836+
name = "lifetimes4"
837+
dir = "16_lifetimes"
838+
test = false
839+
hint = """
840+
Lifetimes can be elided if the compiler can infer a sensible default choice:
841+
https://doc.rust-lang.org/reference/lifetime-elision.html
842+
843+
In most cases, the default choice is correct.
844+
But occasionally, the default choice does not follow our intent.
845+
Can you spot an elided lifetime which might not be correct?
846+
You can think about what the compiler's default choice is for every elided lifetime.
847+
Where could you add an explicit lifetime annotation to better express what we want?
848+
"""
849+
835850
# TESTS
836851

837852
[[exercises]]
Lines changed: 60 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,60 @@
1+
// Sometimes, we have structs which hold on to data temporarily. A use-case of
2+
// this could be a routing component which accepts a connection and returns it to
3+
// another recipient. To avoid copying the data, we just accept a reference with
4+
// lifetime and return this reference later.
5+
//
6+
// In the example below, we create a `Router` instance in a limited scope. It
7+
// accepts a connection reference created in the enclosing scope and returns it.
8+
// In theory, this should be possible given that the connection reference outlives
9+
// the scope from which it is returned. However, the borrow checker does not
10+
// seem to understand it. What can we do about that?
11+
12+
struct Router<'a> {
13+
connection: Option<&'a u64>,
14+
// ^^ lifetime of the connection reference
15+
// which may outlive the `Router` itself
16+
}
17+
18+
impl<'a> Router<'a> {
19+
fn new() -> Self {
20+
Self { connection: None }
21+
}
22+
23+
fn accept_connection(&mut self, connection: &'a u64) {
24+
self.connection = Some(connection);
25+
}
26+
27+
fn return_connection(&mut self) -> Option<&'a u64> {
28+
// added lifetime annotation ^^
29+
//
30+
// Without annotation, the compiler infers the output reference
31+
// to have the lifetime of the only input reference
32+
// -> the lifetime of `&mut self`.
33+
self.connection.take()
34+
}
35+
}
36+
37+
fn main() {
38+
let connection = &123;
39+
40+
let returned_connection = {
41+
// Create router within scope
42+
let mut router = Router::new();
43+
44+
// Accept connection which lives longer than the router
45+
router.accept_connection(connection);
46+
47+
// Return connection which **should** live longer than the router
48+
router.return_connection()
49+
// ^^^^^^^^^^^^^^^^^^^^
50+
//
51+
// Without the explicit lifetime annotation in `return_connection`,
52+
// the reference from `return_connection` has the lifetime of `router`.
53+
// We are returning the reference from the scope, requiring it to outlive it,
54+
// so the compiler complains about `router` not living long enough.
55+
};
56+
57+
if let Some(connection) = returned_connection {
58+
println!("The connection is {connection}");
59+
}
60+
}

0 commit comments

Comments
 (0)