AsRef is weird. I still haven't fully absorbed it. Borrow is weird too. Thanks for the video. The case sensitive aspect makes sense now. It's interesting that they have the same trait signature, but I guess it's just that the intent is different, so made sense to have 2. And just that the ownership semantics are different. You Borrow from an owned, and you AsRef from a ref. You can AsRef to many different types, so it's not just "the one and only thing inside". What I figured out is it's really just about flexibility of APIs? "As long as you can as_ref to the type expected in the parameter, you can pass your object in". Part of the AsRef weirdness is just that Option::as_ref() and Result::as_ref() trip people up into thinking their part of that trait. Those also trip people up - myself included for a while.
Thanks a lot, this really helped! Especially the last part. Now I understand why Borrow can be used in a real HashMap like that. Implementing Borrow implies that the borrowed Type is getting the same hash by convention. Makes sense!
AsRef is to be used for cheap conversions. Basically cheap object to pointer, or pointer to pointer conversions. Borrow is to be used to obtain some reference to an owned type
Hey! great video, it really helped me a lot. I just want to mention that actually the statement: `fhm.get("key")` would return None and not the incorrect value. That is due to the difference on `Hash` trait implementation for `str` and `CaseInsensitiveString`.
Hey - sorry for taking a while to get back to you! To clarify, 𝙲𝚊𝚜𝚎𝙸𝚗𝚜𝚎𝚗𝚜𝚒𝚝𝚒𝚟𝚎𝚂𝚝𝚛(..) implements the equality traits so that 𝙲𝚊𝚜𝚎𝙸𝚗𝚜𝚎𝚗𝚜𝚒𝚝𝚒𝚟𝚎𝚂𝚝𝚛("𝚔𝚎𝚢") == 𝙲𝚊𝚜𝚎𝙸𝚗𝚜𝚎𝚗𝚜𝚒𝚝𝚒𝚟𝚎𝚂𝚝𝚛("𝙺𝙴𝚈"), so 𝚏𝚑𝚖.𝚐𝚎𝚝("𝚔𝚎𝚢") will return 𝙲𝚊𝚜𝚎𝙸𝚗𝚜𝚎𝚗𝚝𝚒𝚝𝚒𝚟𝚎𝚂𝚝𝚛("𝚅𝙰𝙻𝚄𝙴"), which, in concept, is incorrect - i.e., we got a 'hash' collision for two keys that should not match. This is to highlight that, w/ this, we should use 𝙰𝚜𝚁𝚎𝚏, as the equality traits don't work the same and that's a usage requirement between the borrowed and owned type for 𝙱𝚘𝚛𝚛𝚘𝚠.
Hey! It's not really a code editor - I just used mdbook: crates.io/crates/mdbook You can see my source code for it here: github.com/danbugs/danlogs/tree/master/Rust/The%20Rust%20Programming%20Language%20-%20Tutorials/extra/asref_borrow
![กี่หมื่นฟ้า | Your Sky Series EP.1 [1/4]](http://i.ytimg.com/vi/vLGjxFL6U_I/mqdefault.jpg)
AsRef is weird. I still haven't fully absorbed it. Borrow is weird too. Thanks for the video. The case sensitive aspect makes sense now. It's interesting that they have the same trait signature, but I guess it's just that the intent is different, so made sense to have 2. And just that the ownership semantics are different. You Borrow from an owned, and you AsRef from a ref. You can AsRef to many different types, so it's not just "the one and only thing inside". What I figured out is it's really just about flexibility of APIs? "As long as you can as_ref to the type expected in the parameter, you can pass your object in".
Part of the AsRef weirdness is just that Option::as_ref() and Result::as_ref() trip people up into thinking their part of that trait. Those also trip people up - myself included for a while.
Thanks a lot, this really helped! Especially the last part. Now I understand why Borrow can be used in a real HashMap like that. Implementing Borrow implies that the borrowed Type is getting the same hash by convention. Makes sense!
AsRef is to be used for cheap conversions. Basically cheap object to pointer, or pointer to pointer conversions.
Borrow is to be used to obtain some reference to an owned type
Hey! great video, it really helped me a lot. I just want to mention that actually the statement: `fhm.get("key")` would return None and not the incorrect value. That is due to the difference on `Hash` trait implementation for `str` and `CaseInsensitiveString`.
Hey - sorry for taking a while to get back to you!
To clarify, 𝙲𝚊𝚜𝚎𝙸𝚗𝚜𝚎𝚗𝚜𝚒𝚝𝚒𝚟𝚎𝚂𝚝𝚛(..) implements the equality traits so that 𝙲𝚊𝚜𝚎𝙸𝚗𝚜𝚎𝚗𝚜𝚒𝚝𝚒𝚟𝚎𝚂𝚝𝚛("𝚔𝚎𝚢") == 𝙲𝚊𝚜𝚎𝙸𝚗𝚜𝚎𝚗𝚜𝚒𝚝𝚒𝚟𝚎𝚂𝚝𝚛("𝙺𝙴𝚈"), so 𝚏𝚑𝚖.𝚐𝚎𝚝("𝚔𝚎𝚢") will return 𝙲𝚊𝚜𝚎𝙸𝚗𝚜𝚎𝚗𝚝𝚒𝚝𝚒𝚟𝚎𝚂𝚝𝚛("𝚅𝙰𝙻𝚄𝙴"), which, in concept, is incorrect - i.e., we got a 'hash' collision for two keys that should not match. This is to highlight that, w/ this, we should use 𝙰𝚜𝚁𝚎𝚏, as the equality traits don't work the same and that's a usage requirement between the borrowed and owned type for 𝙱𝚘𝚛𝚛𝚘𝚠.
Thanks! It was very informative, and in the end I did understand the difference between two of them :)
Oh this is some excellent Rust content 👌
this is cool, deep dive
I couldn't figure out which web-based Rust code editor you use in this video. Could you give a hint about it?
Hey! It's not really a code editor - I just used mdbook: crates.io/crates/mdbook
You can see my source code for it here: github.com/danbugs/danlogs/tree/master/Rust/The%20Rust%20Programming%20Language%20-%20Tutorials/extra/asref_borrow