Rust 2018 - Modules, External Crates, Submodules, Paths and Visibility Modifiers

Key Takeaways

hey guys my name is tensor today we're gonna be looking at the new module system that was added in the rust 2018 edition a lot of people found the original module system to be a bit confusing especially when they first started working with rust in an effort to make it a little bit easier to understand they've added a lot of new features that make it much more intuitive now first of all I recommend that you guys go ahead and update your version of rust so that you can use these new features and to facilitate that I recommend that you download the rust up tool if you haven't already rust up will allow you to have multiple different rust tool chains on your system at the same time so you can have the nightly tool chain and the stable tool chain at the same time also I won't be covering every little niche case in the module system so you can come to this addition guide and check out some of the new changes now there are a lot of changes to rust 2018 outside of the module system and we will get to some of these in their own videos for instance I'm going to make a video on futures and streams and I'm also going to make a video on the new trait system and the new lifetime modifiers with that out of the way if you've gone ahead and you've created a new project with cargo on the latest version of rust you'll notice that inside of your cargo dot Tamil you'll have a new key called addition and the addition will be by default set to 2018 if you're working with an older project you can go ahead and add this key and then add 2018 as well and then that will give you access to these new features now as far as I know most of these features are not breaking changes so you should be able to still use the old 2015 notations without any problem but there might be some small use cases where you do have some kind of breaking change so I do recommend that you migrate your code from 2015 to 18 fairly slowly there's also a tool that you can use which will take 2015 code and change it into 2018 code and I'll link that tool in the description of this video so that you guys can go and take a look at it now notice for this project I've imported two libraries lazy static and Rand and we're going to use these two libraries in our example so in rust 1.0 if you wanted to bring in an external library you would have to use the keywords external a followed by the name of the library and if the library had macros that you wanted to use you would have to use this procedural macro above the import to tell the compiler that you want to bring in those macros as well none of this is necessary anymore so instead of calling extern crate I can go ahead and just say use and then the name of the library so in this case I'm just saying use Rand and that allows me to call Rand random and then with the lazy static macro I can directly import it because it is now at the root of the lazy static library so if you have a library and that library has macros inside of it those macros will now be located inside of the top sub module of the library by default and this is something that was added to the macro system to make it much easier to work with the new module system I also plan to make a video on the macro system so we'll go into more detail about the specifics of this feature so as a summary if you want to use an external crate in your project all you have to do is add it to your cargo tunnel file and then once you've done that you can just reference it like you would with any other module inside of your application so as you can see here I'm inside of a sub module called sub and inside of a function called example and I can go ahead and just call Rand random without using the use keyword for so I don't have to specify that I'm importing an external module in any way shape or form it just works there is one exception to this rule for now and that has to do with the cysts crates these are crates which are distributed with Rus itself and they will eventually work like this though for now they do need the external a declaration with the external crate key words we could also import libraries with an alias using the as keyword so in this case I'm importing Rand and I'm saying alias it as R and then I can go ahead and use it inside of the project of course now we don't use externally so we need another way to alias our libraries if we want to do that so now instead we can Arius the library just using the used keyword and we can just say use R and as R like that and as you can see here we can so reference it as Rand inside of a sub module but inside of the module that we're saying use R and s are it is referenced to as R along with all these other changes they've made some pretty big changes to how sub modules work so in the past if you wanted to make a sub module say example and you wanted to put it into a folder so that that sub module could have other sub modules attached to it you would have to use a mod RS file and a consequence of this is the fact that you couldn't have a file called example dot RS as well because then it would just get confused and it wouldn't know which one was the sub module now instead of having the mod RS file you create a file called example which acts like that mod RS file except it's not inside of the folder so example is a sub module of our main dot RS file and it has two sub modules associated with it those sub modules go into a folder called example so as you can see here inside of example dot RS we have mod sub and mod sub two and that means that these two files are now sub modules of our example sub module personally I find this to be a bit easier to work with and to reason about since the file and the folder have the same name you know that everything inside of this folder is associated with the file whereas before you just had the folder in the mod RS and it wasn't clear that the mod dot RS file was the main module of the folder now along with these sub module changes there have been some more path changes so how we reference sub modules and modules outside of our application and stuff like that has changed slightly and it has become much more consistent so inside of both of these sub modules I've created functions so this just prints out from sub and then this other one just prints out from sub to the birth called sub of course and they're using pubs so that we can access them inside of our main dot RS file also inside of example dot RS both of these modules are public as well so say I want to call those two functions from our main function I can go ahead and use the use keyword to get example sub an example sub two and if I wanted to I can preface both of these with a crate keyword and what this crate keyword does is it basically just tells us that these two sub modules exist inside of our main crate now of course the crate keyword in this case is not necessary so I can just take it away because example is a sub module of main so we can still call to example sub an example sub two by simply just calling example sub an example sub two like this and then of course inside of main we can call the two functions just by referencing these sub modules now let's say for example we want to do the same thing that we did before with our main function but with another function that we'll just call a function so we want to call the sub function from both sub and sub two we can just use the crate keyword and then of course reference them using example and sub and sub two now because example is not a sub module of test you can see that when I take away the crate keyword both of these imports start to throw errors because it doesn't know where these modules are supposed to be in context with the test module this crate keyword can also be used as a visibility modifier so with our function here called a function if we want to expose this function to our entire crate we can just say pub and then in parenthesis we can put crate and what this does is it just makes it so that we can call this function inside of the crate but it can't be called from outside of the crate so if we were to use this project as a dependency then we wouldn't have access to the a function function but if we were just to specify it as pub and not say crate then this function would be accessible from outside of this crate we can also use the super keyword as a visibility modifier and all this really does is it exposes this function to the ancestor module of the sub module so in this case it exposes it to our main sub module so if I go ahead and I wrap the test subcon a function can only be called from inside of the sub sub module and it can't be called in our main sub module anymore another way that we can expose this function only to the sub module is by explicitly saying that we want it to be in that sub module here we're just saying in create sub so now this function is only visible inside of the sub sub module I'd say that this last type of visibility modifier is pretty nice but it can be useful if you really need to divide your functions sub-modules and data from one another here's another example of how the paths work so for instance I'm calling to the external ran random function inside of this sub module test and we've also got another sub module inside of test called sub which has a struct called sub which we only want to be accessible inside of the test submarine ohm here which is public to our entire application and to any external applications and then we've got our a function down here which is accessing the standard library and it's also accessing our inu and of course we can pattern match on that inu so the use keyword can work in various different contexts the way that we're importing all this stuff can work in any context so even if we were to wrap this in multiple sub modules or if we were to just take all this code and put it into our main dot RS file directly it would all still work the final thing I want to take a look at today is how imports have changed it's not very uncommon for you to see imports that look like this from the standards library so in this case I'm importing from standard FS I'm importing from standard i/o and I'm importing from standard path and of course all of these use statements share the standard library in common to make things easier rust has given us nested import statements so as you can see here I've taken all of these use statements and I've combined them into a single statement because they all come from the standard library we can just say use standard and then use some curly brackets to get FS io and path and of course this will work for any kind of sub module and any kind of tight so say I wanted to import from our example module a bunch of different types and maybe some functions from the sub sub modules as well I could do that all in a single use statement alright guys well I hope you enjoyed video if you did feel free to like and subscribe if you have any questions or comments feel free to leave them in the box below and if you dislike this video then by all means download it as much as you like if you want to see more videos like this then go ahead and click that notification Bell and if you'd like to subvert the channel then go ahead and check out the patreon have a good night