You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
First of all thanks for the exercises, it's great resources are available online!
I open this issue because I think some crucial explanation is missing when lifetimes are introduced, but I'm not sure if an explanation exists in the Rust ecosystem in general (I discussed this with our local Rust Evangelist, who couldn't point me to a reassuring answer either). I get that lifetimes are complex, but my concern is mainly about the syntax one should use to express lifetime constraints, assuming full understanding of the concept of lifetimes and program logic.
Say we want to solve exercise 6.16 - BTreeMap, where we are supposed to implement an IntoIterator. Let's say we also figured out the IntoIter type based on the official docs:
As I understand this notion is not relevant to actual lifetimes of memory structures, but is only a syntactic element that introduces the lifetime identifier. After introducing the lifetime the compiler gives the following error:
error[E0207]: the lifetime parameter 'a is not constrained by the impl trait, self type, or predicates
"Error example 4" in rustc --explain E0207 matches this exact case, but gives no resolution except pointing to the RFC, that has no mention of lifetimes at all!
The only "solution" I found is to get a hint from the "impl trait, self type or predicates" E0207 error and try to squeeze lifetime parameters around &TicketStore, but even the Rust Book doesn't have mention of the &'a TicketStore syntax that should be used here based on the provided solution.
I think it'd spare a lot of frustration if the expected syntax elements would be at least briefly described, preferably with links to further explanations about their roles.
The text was updated successfully, but these errors were encountered:
I'd like to once again thank @estebank for picking this up! I believe rust-lang/rust#135604 (now merged to master) is a major step forward to make the solution to the exercise problem discoverable.
First of all thanks for the exercises, it's great resources are available online!
I open this issue because I think some crucial explanation is missing when lifetimes are introduced, but I'm not sure if an explanation exists in the Rust ecosystem in general (I discussed this with our local Rust Evangelist, who couldn't point me to a reassuring answer either). I get that lifetimes are complex, but my concern is mainly about the syntax one should use to express lifetime constraints, assuming full understanding of the concept of lifetimes and program logic.
Say we want to solve exercise 6.16 - BTreeMap, where we are supposed to implement an
IntoIterator
. Let's say we also figured out theIntoIter
type based on the official docs:(The above code also assumes that one figures out that (despite
IntoIter
is specified withTicket
)Item
should be&Ticket
)The compiler gives the following error:
... and suggests to introduce the lifetime in
impl
. (Note that the other compiler suggestion leads to a deep rabbit hole!)impl<'a>
syntax is mentioned here in the Rust Book, but nowhere in the Exercise Book:As I understand this notion is not relevant to actual lifetimes of memory structures, but is only a syntactic element that introduces the lifetime identifier. After introducing the lifetime the compiler gives the following error:
"Error example 4" in
rustc --explain E0207
matches this exact case, but gives no resolution except pointing to the RFC, that has no mention of lifetimes at all!The only "solution" I found is to get a hint from the "impl trait, self type or predicates" E0207 error and try to squeeze lifetime parameters around
&TicketStore
, but even the Rust Book doesn't have mention of the&'a TicketStore
syntax that should be used here based on the provided solution.I think it'd spare a lot of frustration if the expected syntax elements would be at least briefly described, preferably with links to further explanations about their roles.
The text was updated successfully, but these errors were encountered: