You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We've merged PR rust-lang#1040, so we can remove the TODO and update the link
to point to the specific section.
We replace some commas with semicolons where that's the right thing to
do grammatically.
Where we have "an X is... they are...", we replace that with "an X
is... Xs are..." for reasons of avoiding a mismatch between the
plurality of the pronoun and its referent.
We replace "implementing type" and "defining type" with "type being
implemented" and "type being defined", since there is in general a
difference (e.g. "the driving force" vs "the force being driven"), and
these seem more like the latter than the former.
There's a place where we had said, "glob imports are allowed to import
conflicting names into the same *namespaces*" (emphasis added). It
makes sense what this is trying to say by using the plural there. But
it just reads better to use the singular, and if it's true for the
singular, it's clearly also true to the plural, so we make that
change.
The trait declaration defines the trait in the [type namespace] of the module or block where it is located.
21
-
Associated items are defined as members of the trait within their respective namespaces: type namespace for associated types, and value namespace for constants and functions.
20
+
The trait declaration defines a trait in the [type namespace] of the module or block where it is located.
21
+
Associated items are defined as members of the trait within their respective namespaces. Associated types are defined in the type namespace. Associated constants and associated functions are defined in the value namespace.
22
22
23
23
All traits define an implicit type parameter `Self` that refers to "the type
24
24
that is implementing this interface". Traits may also contain additional type
Copy file name to clipboardExpand all lines: src/items/use-declarations.md
+34-31
Original file line number
Diff line number
Diff line change
@@ -13,7 +13,7 @@ A _use declaration_ creates one or more local name bindings synonymous with
13
13
some other [path]. Usually a `use` declaration is used to shorten the path
14
14
required to refer to a module item. These declarations may appear in [modules]
15
15
and [blocks], usually at the top.
16
-
A `use` declaration is also sometimes called an _import_ or if it is public it is a _re-export_.
16
+
A `use` declaration is also sometimes called an _import_, or, if it is public, a _re-export_.
17
17
18
18
[path]: ../paths.md
19
19
[modules]: modules.md
@@ -99,7 +99,7 @@ They may create bindings for:
99
99
100
100
They cannot import [associated items], [generic parameters], [local variables], paths with [`Self`], or [tool attributes]. More restrictions are described below.
101
101
102
-
`use` will create bindings for all [namespaces] from the imported entities, with the exception of a `self` import (described below) which only imports the type namespace.
102
+
`use` will create bindings for all [namespaces] from the imported entities, with the exception that a `self` import will only import from the type namespace (as described below).
103
103
For example, the following illustrates creating bindings for the same name in two namespaces:
104
104
105
105
```rust
@@ -111,12 +111,12 @@ mod stuff {
111
111
usestuff::Foo;
112
112
113
113
fnexample() {
114
-
letctor=Foo; //From value namespace
115
-
letx:Foo=ctor(123);
114
+
letctor=Foo; //Uses `Foo` from the value namespace.
115
+
letx:Foo=ctor(123);// Uses `Foo` From the type namespace.
116
116
}
117
117
```
118
118
119
-
> **Edition Differences**: In the 2015 edition, `use` paths are relative from the crate root.
119
+
> **Edition differences**: In the 2015 edition, `use` paths are relative to the crate root.
120
120
> For example:
121
121
>
122
122
> ```rust,edition2015
@@ -127,7 +127,8 @@ fn example() {
127
127
> mod bar {
128
128
> // Resolves `foo` from the crate root.
129
129
> use foo::example::iter;
130
-
> // :: prefix explicitly resolves `foo` from the crate root.
130
+
> // The `::` prefix explicitly resolves `foo`
131
+
> // from the crate root.
131
132
> use ::foo::baz::foobaz;
132
133
> }
133
134
>
@@ -154,25 +155,25 @@ mod inner {
154
155
155
156
## Brace syntax
156
157
157
-
Braces can be used in the last segment of the path to import multiple entities from the previous segment or the current scope if there are no previous segments.
158
+
Braces can be used in the last segment of the path to import multiple entities from the previous segment, or, if there are no previous segments, from the current scope.
158
159
Braces can be nested, creating a tree of paths, where each grouping of segments is logically combined with its parent to create a full path.
An empty brace does not import anything, though the leading path is validated that it is accessible.
169
-
<!-- This is slightly wrong, see https://github.com/rust-lang/rust/issues/61826 -->
170
+
<!-- This is slightly wrong, see: https://github.com/rust-lang/rust/issues/61826 -->
170
171
171
-
> **Edition Differences**: In the 2015 edition, paths are relative to the crate root, so an import such as `use {foo, bar};` will import the names `foo` and `bar` from the crate root, whereas starting in 2018 those names are relative to the current scope.
172
+
> **Edition differences**: In the 2015 edition, paths are relative to the crate root, so an import such as `use {foo, bar};` will import the names `foo` and `bar` from the crate root, whereas starting in 2018, those names are relative to the current scope.
172
173
173
174
## `self` imports
174
175
175
-
The keyword `self` may be used in the[brace syntax](#brace-syntax) to create a binding of the parent entity under its own name.
176
+
The keyword `self` may be used within[brace syntax](#brace-syntax) to create a binding of the parent entity under its own name.
176
177
177
178
```rust
178
179
modstuff {
@@ -204,7 +205,7 @@ mod bar {
204
205
use bar::foo::{self};
205
206
206
207
fn main() {
207
-
foo(); // Error, `foo` is a module
208
+
foo(); //~ ERROR `foo` is a module
208
209
}
209
210
```
210
211
@@ -228,7 +229,8 @@ mod foo {
228
229
V2,
229
230
}
230
231
pubfnbar() {
231
-
// Creates local aliases to V1 and V2 of the Example enum.
232
+
// Creates local aliases to `V1` and `V2`
233
+
// of the `Example` enum.
232
234
useExample::*;
233
235
letx=V1;
234
236
}
@@ -240,9 +242,9 @@ That is, if there is a name already defined by another item in the same namespac
240
242
For example:
241
243
242
244
```rust
243
-
// This creates a binding to the `clashing::Foo` tuple struct constructor, but
244
-
// does not import its type because that would conflict with the `Foo` struct
245
-
// defined here.
245
+
// This creates a binding to the `clashing::Foo` tuple struct
246
+
//constructor, but does not import its type because that would
247
+
//conflict with the `Foo` struct defined here.
246
248
//
247
249
// Note that the order of definition here is unimportant.
248
250
useclashing::*;
@@ -251,11 +253,12 @@ struct Foo {
251
253
}
252
254
253
255
fndo_stuff() {
254
-
// Uses the constructor from clashing::Foo
256
+
// Uses the constructor from `clashing::Foo`.
255
257
letf1=Foo(123);
256
-
// The struct expression uses the type from the Foo struct defined above.
258
+
// The struct expression uses the type from
259
+
// the `Foo` struct defined above.
257
260
letf2=Foo { field:1.0 };
258
-
//Also imported from the glob import.
261
+
//`Bar` is also in scope due to the glob import.
259
262
letz=Bar {};
260
263
}
261
264
@@ -268,7 +271,7 @@ mod clashing {
268
271
`*` cannot be used as the first or intermediate segments.
269
272
`*` cannot be used to import a module's contents into itself (such as `use self::*;`).
270
273
271
-
> **Edition Differences**: In the 2015 edition, paths are relative to the crate root, so an import such as `use *;` is valid, and it means to import everything from the crate root.
274
+
> **Edition differences**: In the 2015 edition, paths are relative to the crate root, so an import such as `use *;` is valid, and it means to import everything from the crate root.
272
275
> This cannot be used in the crate root itself.
273
276
274
277
## Underscore Imports
@@ -317,10 +320,10 @@ m!(use std as _;);
317
320
318
321
## Restrictions
319
322
320
-
The following are restrictions for valid `use` declarations.
323
+
The following are restrictions for valid `use` declarations:
321
324
322
-
*`use crate;` must use `as` to define the name to bind the crate root to.
323
-
*`use {self};` is an error, there must be a leading segment when using `self`.
325
+
*`use crate;` must use `as` to define the name to which to bind the crate root.
326
+
*`use {self};` is an error; there must be a leading segment when using `self`.
324
327
* As with any item definition, `use` imports cannot create duplicate bindings of the same name in the same namespace in a module or block.
325
328
*`use` paths with `$crate` are not allowed in a [`macro_rules`] expansion.
326
329
*`use` paths cannot refer to enum variants through a [type alias]. Example:
@@ -330,17 +333,17 @@ The following are restrictions for valid `use` declarations.
330
333
}
331
334
type TypeAlias = MyEnum;
332
335
333
-
use MyEnum::MyVariant; // OK
334
-
use TypeAlias::MyVariant; // ERROR
336
+
use MyEnum::MyVariant; //~ OK
337
+
use TypeAlias::MyVariant; //~ ERROR
335
338
```
336
339
337
340
## Ambiguities
338
341
339
342
> **Note**: This section is incomplete.
340
343
341
-
Some situations are an error when there is an ambiguity as to which name a `use` declaration refers to, when there are two name candidates that do not resolve to the same entity.
344
+
Some situations are an error when there is an ambiguity as to which name a `use` declaration refers. This happens when there are two name candidates that do not resolve to the same entity.
342
345
343
-
Glob imports are allowed to import conflicting names in the same namespaces as long as the name is not used or shadowed.
346
+
Glob imports are allowed to import conflicting names in the same namespace as long as the name is not used or shadowed.
0 commit comments