rust-unofficial
Effectively naming lifetimes to help improve code clarity
Interesting and I wonder if that wouldn't be a good addition to this repository? https://web.archive.org/web/20210521022017/https://www.possiblerust.com/pattern/naming-your-lifetimes
Thoughts?
https://www.possiblerust.com/pattern/naming-your-lifetimes
I don't think it is good. It's up to the users and authors how they want to name stuff, some prefer single character some prefer multi characters, but either way both ways works and we should not specifically encourage one or the other, they should think which one is best for the task.
I don't think it is good. It's up to the users and authors how they want to name stuff, some prefer single character some prefer multi characters, but either way both ways works and we should not specifically encourage one or the other, they should think which one is best for the task.
I think it's like every so often, I agree, that we shouldn't encourage one or another approach but explain what can be achieved by it and how. Giving (dis-)advantages of either approach and talking about the thought process when naming your lifetimes. When you say "they should think which one is best for the task", what if some people have never thought about it before and want to read something about it. Why shouldn't they read something in a rust patterns book about it how others do that? This book should be educational in these ways, also if it's often subjective to the author of the article. But this we can fix over time (the PR review process) and when other people read through it and give feedback.
Just wondering, shouldn't this already be mentioned in the book? Talking about that here is like talking about naming variables, very sensitive. Like c vs counter.
Just wondering, shouldn't this already be mentioned in the book? Talking about that here is like talking about naming variables, very sensitive. Like c vs counter.
The book talks more about the "what, why and how to use" and they use for their examples lifetimes with the names 'a and 'b. Which is something we could state again, that you can do it like that, but that loses you much clarity in a complex codebase and that sometimes it's better to give them more explicit names and how to chose them accordingly.