5 ms·

This is a fantastic list. I've certainly learned something new. The comments here are unnecessary negative. People seem to be upset on things that don't look

by ww520 4y ago

This is a fantastic list. I've certainly learned something new. The comments here are unnecessary negative. People seem to be upset on things that don't look familiar. Don't let the negative comments get to you. Keep up the good work.

mvolfik 4y ago
I don't think the comments mean to say the list is useless. It's a nice overview and I learned a few things as well. However, having written non-trivial amount of code in Rust, it really struck me at how many places there are various factual errors (however small they are). And yes, Rust is a complex lang, but if you mix terms like this without noticing the differences, I'm afraid that will make it easier. To add an example of my own: fn do_the_meow(meower: Meower) seems like you want to take (consume, own) an object implementing Meower, which is correctly explained not possible like this. A suggested solution, fn do_the_meow(meower: &dyn Meower) is very different - it is now correct with regards to a trait access, however, now you're just taking a reference. Correct replacement would be Box<dyn Meower>. And the final solutions, fn do_the_meow<M: Meower>(meower: M) fn do_the_meow(meower: &impl Meower) the first one is correct and equivalent to the original intent - it takes (owns) the value. However, the second variant (which is, again, as correctly stated, the best solution), is different again - it takes a reference (`&`) to `impl Meower`. Coming back to my point - it is important to separate the difference between the ampersand and the impl/dyn part. To suggest an improvement, one could first write all variants of this function taking a reference (`&Meower`, `&dyn Meower`, `&M` and `&impl Meower`), and later introduce the difference between where one can use sized/unsized types, and that Box<dyn Meower> is owned equivalent of &dyn Meower, and why one can't have owned `dyn Meower` just lying around.

by ww520 4y ago

mvolfik 4y ago

I don't think the comments mean to say the list is useless. It's a nice overview and I learned a few things as well. However, having written non-trivial amount of code in Rust, it really struck me at how many places there are various factual errors (however small they are). And yes, Rust is a complex lang, but if you mix terms like this without noticing the differences, I'm afraid that will make it easier. To add an example of my own: fn do_the_meow(meower: Meower) seems like you want to take (consume, own) an object implementing Meower, which is correctly explained not possible like this. A suggested solution, fn do_the_meow(meower: &dyn Meower) is very different - it is now correct with regards to a trait access, however, now you're just taking a reference. Correct replacement would be Box<dyn Meower>. And the final solutions, fn do_the_meow<M: Meower>(meower: M) fn do_the_meow(meower: &impl Meower) the first one is correct and equivalent to the original intent - it takes (owns) the value. However, the second variant (which is, again, as correctly stated, the best solution), is different again - it takes a reference (`&`) to `impl Meower`. Coming back to my point - it is important to separate the difference between the ampersand and the impl/dyn part. To suggest an improvement, one could first write all variants of this function taking a reference (`&Meower`, `&dyn Meower`, `&M` and `&impl Meower`), and later introduce the difference between where one can use sized/unsized types, and that Box<dyn Meower> is owned equivalent of &dyn Meower, and why one can't have owned `dyn Meower` just lying around.