-
Notifications
You must be signed in to change notification settings - Fork 530
Document preludes #415
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Document preludes #415
Conversation
src/crates-and-source-files.md
Outdated
## Preludes and `no_std` | ||
|
||
All crates have a *prelude* that automatically inserts a [use declaration] into | ||
each [module] and an [`extern crate]` into the crate root module. By default, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is not how it works and there are observable differences.
(Will explain later, need to go now.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm still blocked on this explanation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry, I completely forgot about this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Prelude names are not placed in any modules with use
declarations, they are just added into scope.
So you can write Vec<T>
in any module, but not self::Vec<T>
- ther's no Vec
in any module.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we look at some other names that are placed into scope rather than into modules
{
let x = 10;
{
let x = 11;
{
let x = 12;
{
x
}
}
}
}
then we can extend this hierarchy with one more outer level and place prelude names there, that's the effect of std prelude injection.
A number of other names behaves in the same way, e.g. built-in types, or macros imported with #[macro_use] extern crate ...
, or extern crates with feature(extern_prelude)
(that's currently being stabilized in rust-lang/rust#54404),
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So
#[prelude_import]
use std::prelude::v1::*;
that you can see in the root module after running a crate through --pretty=expanded
is not really a use
item, it's just some arbitrary syntax that contains a module name that compiler can detect and do its job by putting names from that module into scope.
(It could be prelude std::prelude::v1;
instead, or something, but we decided not to invent a new syntax for this implementation detail.)
The last two weeks of work have been hard on me, but I finally got the energy to properly update this today. @petrochenkov, does this accurately describe the prelude now? Paths and path resolution need a new look at in the future, so I'm not too worried with the writing about "in scope" or whatnot being technically specific at this moment. |
src/crates-and-source-files.md
Outdated
each [module] and an [`extern crate]` into the crate root module. By default, | ||
the *standard prelude* is used. The linked crate is [`std`] and the [use | ||
delcaration] uses [`std::prelude::v1::*`]. | ||
All crates have a *prelude* that automatically inserts paths of a specific |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"of" -> "from" would be better?
src/items/modules.md
Outdated
@@ -68,8 +68,12 @@ mod thread { | |||
} | |||
``` | |||
|
|||
Modules implicitly have a [use declaration] specified by crate's [prelude]. The | |||
[use declaration] can be removed by using the `no_implicit_prelude` [attribute]. | |||
Modules implicitly have some paths in scope. These paths are to built-in types, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"paths" -> "names", names are in scope.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Path is a higher level thing in general, the first segment is searched in the current scope, the following segments are searched in modules (or in impls if they are associated items). Path as a whole being in scope doesn't make much sense.
Both changes have been made. |
Rebased against master. r? @matthewjasper or @alercah |
All crates have a *prelude* that automatically inserts names from a specific | ||
module, the *prelude module*, into scope of each [module] and an [`extern | ||
crate]` into the crate root module. By default, the *standard prelude* is used. | ||
The linked crate is [`std`] and the prelude module is [`std::prelude::v1`]. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I had a question. By default, aren't both std
and core
crates included in the extern prelude? I also think std
is in the prelude for no_std
, but that might change soon: rust-lang/rust#54658
Also, would it be helpful to describe the different preludes and scope layers? It may not be super relevant, but it might help clarify precedence when there are name conflicts (additions to the standard prelude will not shadow extern crates). IIUC, the layers are:
- local variables
- items in unnamed blocks
- items in the current module
- crate names in the "extern prelude"
- standard library prelude
- language prelude (built-in types)
(The reason I ask is that I was looking at updating extern crate
for the edition, and I'm trying to wrap my head around it.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, all that would be helpful. I didn't know what all the layers were, but if this is the correct list, it's definitely something that should be included.
For core
being included with std
in the extern prelude, I think that's all supposed to change with rust-lang/rust#53128 but I'm not entirely sure.
src/items/functions.md
Outdated
attributes], and [the optimization hint | ||
attributes]. | ||
attributes], and [the optimization hint attributes]. Functions also accept | ||
macro attributes. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
attribute macros?
that have a *dynamic interpretation* govern the behavior of the program at | ||
run-time. | ||
semantic rules that have a *dynamic interpretation* govern the behavior of the | ||
program at run-time. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unrelated, but does this distinction ever appear again?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Const functions perhaps? It's a paragraph that's survived since the reference was originally the guide.
This is still waiting for merge, and I don't perceive an action I need to do in this PR. |
Thanks, I think I was just waiting to see if you wanted to address @ehuss' comment |
I set out to document
no_std
and ended up documenting preludes in general. This also led to the removal of the "Module-only attributes" section as one of its attributes was placed in the prelude attributes section while the other attribute is already documented pretty well on the modules page, so I just linked to it from the attributes page. I wanted to get rid of that section anyways. This means the only two sections in the attribute sections that need to be removed are "crate only attributes" and "misc. attributes". Though having all the sections subsumed under misc attributes was a mistake, and they need to be brought a level higher. I'll do that after this lands, while also sorting them alphabetically.I am generally happy with the new prose I've written in this PR. I specifically added why
no_std
is useful because I see it as a frequently asked question.