yep, especially coming from a linguistics background, it threw me off at the start, but the explanation was otherwise so clear that it didn't matter hahah
Note that it's possible to use an associated type instead of a generic trait, which has the benefit of being usable as reference, for instance in binds (besides, there is no alternative for T so the generic is redundant and only gives more work to the compiler). The changes are minor in the code (unfortunately it's not possible to post URLs here), just remove the after Prefix, add "type Data;" in the trait definition and "Type Data = T;" in the blanket implementation, then replace the remaining "T"s with "Self::Data".
Thanks. This was a really well done video. Your in depth walk-through of the code and types helped a lot. I also thought your example was perfect to get the point across for understanding generics and traits.
Good intro! There really mind blowing things you can done with generics, like instead of defining implementations directly for &[T] from your example we can define one for the types for which Deref coercion to &[T] exists. It is one of the most powerful things in type system and a great way to DRY code as alternative to using macros.
It seems to me, that if we were looking for a subsequence [3, 4, 5] in [1, 2, 3, 4] your program would panic, because (index + prefix.len()) might be larger than the index of the last element in the original vec.
@@chrisbiscardi ngl I missed both the challenge in the description and the possibility of passing an empty slice. Nevertheless this one should do it: fn has_prefix(&self, prefix: &[T]) -> bool { self.iter() .positions(|v| if prefix.is_empty(){ false } else { *v == prefix[0] } ) .find(|&index| { if (self.len() - index) >= prefix.len() { let range = index..(index + prefix.len()); self[range] == *prefix } else { false } }) .is_some() }
Rust shared reference PartialEq compares the value the reference points to, not the pointer itself. doc.rust-lang.org/src/core/cmp.rs.html#1674-1676 when working with raw pointers you'd use ptr::eq or similar instead: doc.rust-lang.org/std/ptr/fn.eq.html
The only drawback of using generics is the rustc monomorphisation process… which takes compilation time as it has to generate functions for every type implementing PartialEq right?
Couldn't you use .any(|window| ...) Instead of .find(|window| ...).is_some()? I guess .any could be faster but I haven't tested it, can be that the compiler just optimizes the unused value away. But I believe .any is a little more clear what it is doing (well not a huge difference either way)
This is actually a warning by default on clippy. warning: called `is_some()` after searching an `Iterator` with `find` note: `#[warn(clippy::search_is_some)]` on by default But it's listed under complexity, not perf, because it's just for readability and doesn't change the compiled code.
Yup. There's a name conflict between the game Rust and the language Rust, so it can be helpful to differentiate, especially on platforms which have both topics
I was very briefly confused by the name "prefix" when it's more of a subsequence, but other than that it was clear.
yep, especially coming from a linguistics background, it threw me off at the start, but the explanation was otherwise so clear that it didn't matter hahah
Thanks for sharing that. Definitely could've chosen a better name there.
@@chrisbiscardi inside_of() ?
has() ?
inside()?
Note that it's possible to use an associated type instead of a generic trait, which has the benefit of being usable as reference, for instance in binds (besides, there is no alternative for T so the generic is redundant and only gives more work to the compiler). The changes are minor in the code (unfortunately it's not possible to post URLs here), just remove the after Prefix, add "type Data;" in the trait definition and "Type Data = T;" in the blanket implementation, then replace the remaining "T"s with "Self::Data".
First channel with such a great deal. After seeing this I felt I don't know anything, I have so much to learn in Rust. Long way to go
Been 8 months since you wrote this, how is it coming along?
I felt like big brain rusty kettle after watching this detailed explanation. Thank you!
Thanks. This was a really well done video. Your in depth walk-through of the code and types helped a lot. I also thought your example was perfect to get the point across for understanding generics and traits.
Awesome explanation. Love that you go over everything in detail
Good intro! There really mind blowing things you can done with generics, like instead of defining implementations directly for &[T] from your example we can define one for the types for which Deref coercion to &[T] exists. It is one of the most powerful things in type system and a great way to DRY code as alternative to using macros.
I didn't expect this to make sense but it did after watching it!! thank you!
Beautiful! Thanks for sharing. Looking forward to more intermediate Rust contents like this. :)
Great content, my favorite Rust youtuber right now!
Great walkthrough especially for newbies, like me.
i love this channel
I like how you named the folder "tmmmmp" 😆
tmmmmp: for when tmp, tmmp, and tmmmp somehow already existed 😆
It seems to me, that if we were looking for a subsequence [3, 4, 5] in [1, 2, 3, 4] your program would panic, because (index + prefix.len()) might be larger than the index of the last element in the original vec.
This should fix it:
fn has_prefix(&self, prefix: &[T]) -> bool {
self.iter()
.positions(|v| *v == prefix[0])
.find(|&index| {
if (self.len() - index) >= prefix.len() {
let range = index..(index + prefix.len());
self[range] == *prefix
} else {
false
}
})
.is_some()
}
Congrats, you were the first person to complete the challenge in the description!
notably prefix[0] could also panic if an empty slice was passed in
@@chrisbiscardi ngl I missed both the challenge in the description and the possibility of passing an empty slice. Nevertheless this one should do it:
fn has_prefix(&self, prefix: &[T]) -> bool {
self.iter()
.positions(|v|
if prefix.is_empty(){
false
} else {
*v == prefix[0]
}
)
.find(|&index| {
if (self.len() - index) >= prefix.len() {
let range = index..(index + prefix.len());
self[range] == *prefix
} else {
false
}
})
.is_some()
}
Excellent video
This is very smart
Is there a reason you can't just use windows() in your trait implementation?
I wanted to show slices and equality is all
really neat, thank you for sharing
Prefix|T> has to be in the same file (inline or module) to be able call has_prefix ?
Traits have to be in scope to use their functions yes
What extension do you use to hide and show the type in vscode or is it part of vscode rust extension? Thanks 🙏
its a plugin called Toggle and I bind the inlay hint hide/show to C-i
@@chrisbiscardi sweet, thanks
At 10:00, why is it the same comparing values or references? Can't references be different but values the same?
Rust shared reference PartialEq compares the value the reference points to, not the pointer itself.
doc.rust-lang.org/src/core/cmp.rs.html#1674-1676
when working with raw pointers you'd use ptr::eq or similar instead: doc.rust-lang.org/std/ptr/fn.eq.html
The only drawback of using generics is the rustc monomorphisation process… which takes compilation time as it has to generate functions for every type implementing PartialEq right?
My assumption is that the compiler only generates it for concrete types that are actually being used in the code, but I don't actually know
@@andr6192 Yes, this is how it works. The compiler only generates it for concrete types where it's used.
Couldn't you use .any(|window| ...) Instead of .find(|window| ...).is_some()? I guess .any could be faster but I haven't tested it, can be that the compiler just optimizes the unused value away.
But I believe .any is a little more clear what it is doing (well not a huge difference either way)
yes you could use .any
This is actually a warning by default on clippy.
warning: called `is_some()` after searching an `Iterator` with `find`
note: `#[warn(clippy::search_is_some)]` on by default
But it's listed under complexity, not perf, because it's just for readability and doesn't change the compiled code.
Rustlang? do you mean Rust?
Yup. There's a name conflict between the game Rust and the language Rust, so it can be helpful to differentiate, especially on platforms which have both topics