Your pseudo-code is pretty much correct. For this example, suppose we had a method call foo.bar() where foo: T. I’m going to use the fully qualified syntax (FQS) to be unambiguous about what type the method is being called with, e.g. A::bar(foo) or A::bar(&***foo). I’m just going to write a pile of random capital letters, … Read more
The thread support in the standard library allows the created threads to outlive the thread that created them; that’s a good thing! However, if you were to pass a reference to a stack-allocated variable to one of these threads, there’s no guarantee that the variable will still be valid by the time the thread executes. … Read more
No, you cannot do it. There are at least two explanations why it is so. First, remember that references are borrowed, i.e. they point to some data but do not own it, it is owned by someone else. In this particular case the string, a slice to which you want to return, is owned by … Read more
It’s easiest to understand what non-lexical lifetimes are by understanding what lexical lifetimes are. In versions of Rust before non-lexical lifetimes are present, this code will fail: fn main() { let mut scores = vec![1, 2, 3]; let score = &scores[0]; scores.push(4); } The Rust compiler sees that scores is borrowed by the score variable, … Read more
Non-answer answer Avoid global state in general. Instead, construct the object somewhere early (perhaps in main), then pass mutable references to that object into the places that need it. This will usually make your code easier to reason about and doesn’t require as much bending over backwards. Look hard at yourself in the mirror before … Read more
The question you asked TL;DR: No, you cannot return a reference to a variable that is owned by a function. This applies if you created the variable or if you took ownership of the variable as a function argument. Solutions Instead of trying to return a reference, return an owned object. String instead of &str, … Read more
TL;DR: One can instead use &str, &[T] or &T to allow for more generic code. One of the main reasons to use a String or a Vec is because they allow increasing or decreasing the capacity. However, when you accept an immutable reference, you cannot use any of those interesting methods on the Vec or … Read more
Let’s look at a simple implementation of this: struct Parent { count: u32, } struct Child<‘a> { parent: &’a Parent, } struct Combined<‘a> { parent: Parent, child: Child<‘a>, } impl<‘a> Combined<‘a> { fn new() -> Self { let parent = Parent { count: 42 }; let child = Child { parent: &parent }; Combined { … Read more
println adds a newline by default (that is what the ln stands for, line). Try to use the print macro instead.
That block defines a new trait called Foo, which then allows you to use the trait in various places such as the impl block you have posted. The : Bar part says that any type that implements Foo must also implement the Bar trait.