Check out a free preview of the full Polyglot Programming: TypeScript, Go, & Rust course

The "Rust Q&A" Lesson is part of the full, Polyglot Programming: TypeScript, Go, & Rust course featured in this preview video. Here's what you'd learn in this lesson:

ThePrimeagen answers student questions regarding name collisions with traits, if traits can be on enums, what happens if &self is passed to foo, and if you can override a preexisting trait such as a system library.


Transcript from the "Rust Q&A" Lesson

>> Does it feel overwhelming right now? Or does it feel like, because most of these concepts you can derive. So if I were to do the exact same thing, this is just class line, is_hory. And then I just do this .p1. It's like the same thing, except for it's split in two locations.

This on the other hand, there's not really a great version of this in JavaScript. Because JavaScript I guess you could have to string. So if you're from string, there's not really like a from string method in the JavaScript world, so how would I derive that? I don't know if there's a great analogous version of this.

But that is effectively if you could parse in JavaScript and just call.parse or something, it would be this. And so, if there are any questions, great time to do it, I'm trying to give extra time. Just because I want to make sure everyone. There's at least one question I can feel it deep down.

I can feel it deep down, we got something.
>> Do you have to be aware or take care of any possible name collisions with traits?
>> No, I don't believe you do. I do not believe you do cuz they're actually well, I bet you yes. You probably do but you probably don't at the same time.

It depends on what you mean by name as far as this type of name. No, I don't believe you do. I've never actually had a name collision. But we could pretty much try to create one pretty easily. You could have a trait Foo, okay. I haven't implemented a trait in a long time so I might actually get this wrong.

And let's go like that. And so there we go. And let's have this thing do a usize. So my guess is that you shouldn't be able to implement both these things. So if I did a imple for Foo for Point. Take that implement this. Bar for Point and then use usize, return 5, return true.

Maybe you can't, I've never actually tried this condition. This is actually neat I'm trying to reason about my head of how you would or what you do with this? You can make a generic values, you can actually constrain them to traits. So theoretically, it would know which traits to call if you constrain your function to take in a specific trait.

And so maybe that's why collisions just simply don't exist in this context, I don't know. Personally, that just blew my mind that you could do that. But I say fantastic.
>> Can you import traits in enums.
>> Yes, so traits can be on, I believe they can be on anything you want.

And you can derive that without looking anything up. Here's an easy way to understand how you can derive it there a little pun there. So I just opened up a new one of these that happens every now and then. So Debug is a trait. I just derived my Debug.

There's traits PartialEq, right. You can derive these things and it works just fine on enums which means just by pure empirical evidence, yes you can. And the answer is yes again. Enums instructs you can have methods on them, I've shown you how to do impose on enums you can also do it there.

So I can create my own personalized display for an enum. Just because if you're printing it out, you may want it to look really nice. And so it'd be silly if I was constrained to not be able to do that, because then I could never actually display it.

So this whole trait, struct enum dance is pretty cool. At least I personally think this actually makes it a really convenient language. It makes it really easy to implement things that are just kind of a little different.
>> What if you parse ampersand self to Foo and bar because right now those are Foo, Foo and bar, bar?

>> I like it, let's find out. Like I said, I've never tried this method, but this seems exciting, so yes. So in other words, if this thing existed on the instance if you will. I still don't think it's gonna make much of a difference. So it doesn't appear to make much of the difference.

Because there you go, you have these two things. I'm curious how this actually plays out. But my guess is you'd want to do something like this. If you were to do this, let's go T, I believe I can just go Bar. I haven't written one of these in a while, so doing this on the spot can be a little interesting let's find out.

So I should be able to go with foo. And it will know, foo returns usize, so there you go. And it can tell it's calling the correct method. And so if I were to change this into a foo, foo now returns a bool. Because I've constrained it to the specific type.

So I think that's why it works. I've to actually go read why that? It just seems like such a funny condition. It's actually a really great question. I would have never thought to ever make my methods the same name ever, because that sounds like it's gonna collide.
>> Can you overwrite a trait that already exists like a system library?

And if so, what trait will be called from the system then? That I don't know the specifics, I know that there's rules around traits. Foreign types foreign trait you can't do those things. But as far as if it already had implementation, you are implementing a trait on a foreign object which I do not believe you can do.

I don't believe you can do that foreign trait on a foreign object. And so that's like the constraint. And so just reasoning about what I do know about Russ, I don't think you can. I couldn't implement because you can't impl on what is it thing if it? Lets say std::f ::File, ipml Display for this and there you go.

Because we neither own Display nor do we own File. And so, we cannot do that. If I'm not mistaken you cannot do that. Only the trait defining the current crate can be implemented for types to find out of the crate. And so my guess is no. But I'd have to think more, I haven't gotten into that kind of stuff.

Plus I think in general programming speak, you should never reimplement standard behaviors, that's always considered such a no, no [LAUGH]. If printing a number changed from one system to the next, that would just be an awful experience. What a very fun bug to debug? Really good somebody.
>> What about bar plus foo?

>> I wonder if that would do it? You could potentially do it. So what he's saying there is that, I like all these, these are great questions. We may have to move on just for time time sake at this point but actually am curious. What does this thing do?

Looks like it's grabbing the first one. Cuz I just switched. So what this means is that this can be a trait object that is constrained that has to be both Bar and foo. And so that's what the plus sign means, very weird syntax. But it looks like it's constraining it to Bar first because Bar was the first one mentioned when I swapped them around.

This is such Twitch chat, just ask every last potential question. We got to move on but this is awesome. I never played around with this area but it looks like you can still do it. At least it appears you can still do it.
>> The Bar plus foo was from Twitch chat.

>> Yea. But the rest were from the Frontend Masters chat,
>> Okay,
>> Just letting me know that.
>> Frontend Masters, you guys are great, I like you guys. Twitch chat, I'm still jury's still out on you guys, I don't know about that.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now