Implementations improvements part 1 #146
Conversation
src/items/implementations.md
Outdated
| | &mut T | ||
| | Box<T> | ||
| | (..., T, ...) | ||
| | X<..., T, ...> where X is not bivariant with respect to T |
There was a problem hiding this comment.
Just C, &T, &mut T and Box<T>.
There was a problem hiding this comment.
This was changed from the RFC then? I was wondering how (..., T, ...) would have worked...
src/items/implementations.md
Outdated
| The nominal type is called the *implementing type* and the associable items are | ||
| the *associated items* to the implementing type. | ||
|
|
||
| Bare implementations associates the associated items to the implementing type. |
src/items/implementations.md
Outdated
|
|
||
| sequence of 'impl' keyword, generic type declarations, nominal type, where clause and the associable items. Generic type declarations and where clause can be omitted, if not needed. The associable items are contained within braces. | ||
|
|
||
| A bare implementation is defined as the sequence of the `impl` keyword, generic |
src/glossary.md
Outdated
| @@ -8,14 +8,21 @@ the structure of the program when the compiler is compiling it. | |||
| ### Arity | |||
|
|
|||
| Arity refers to the number of arguments a function or operation takes. | |||
| For example, `(2, 3)` and `(4, 6)` have arity 2, and`(8, 2, 6)` has arity 3. | |||
| For example, `f(2, 3)` and `g(4, 6)` have arity 2, while `h(8, 2, 6)` has arity 3. | |||
There was a problem hiding this comment.
Having an example that's an operation (not a function) might be good, maybe 4 + 6.
src/glossary.md
Outdated
|
|
||
| An associated item is an item that is associated with another item. Associated | ||
| items are defined in [implementations] and [traits]. Only functions, constants, | ||
| and types can be associated. |
There was a problem hiding this comment.
Hmm, are types associated, or are type aliases associated? You can't put an enum Foo {} in an impl to satisfy a type Foo; in the trait, right?
Is it worth distinguishing between associated items are "declared in traits" and "defined in impls"? The declared/defined words are used in trait impls below.
src/items/implementations.md
Outdated
| Bare implementations associate the associated items to the implementing type. | ||
|
|
||
| The associated item has a path of a path to the implementing type followed by | ||
| the associate item's path component. |
There was a problem hiding this comment.
Maybe note that a bare impl cannot have associated type( aliase)s.
There was a problem hiding this comment.
👍 I had told myself to do that a million times, yet I did not do it.
There was a problem hiding this comment.
(review note, this is resolved below)
src/glossary.md
Outdated
| ### Nominal Types | ||
|
|
||
| Types that can be named directly. Specifically [enums], [structs], [unions], | ||
| and [trait objects]. |
There was a problem hiding this comment.
Is it worth saying that "named" is "referred to by a path", or similar?
Perhaps also add Structural Types, and a cross-ref between them for contrast?
There was a problem hiding this comment.
Worth doing, but in its own PR.
src/items/implementations.md
Outdated
| set of associable items. | ||
|
|
||
| The nominal type is called the *implementing type* and the associable items are | ||
| the *associated items* to the implementing type. |
There was a problem hiding this comment.
Hmm, libcore has impl<T> [T] {, where that slice isn't a nominal type. Users cannot define structural types, though, so they can't do something like that...
There was a problem hiding this comment.
That definitely seems like a special case. Not entirely sure how to document that without messing up the flow for everything else.
|
|
||
| ### Array | ||
|
|
||
| An array, sometimes also called a fixed-size array or an inline array, is a value | ||
| describing a collection of elements, each selected by an index that can be computed | ||
| at run time by the program. It occupies a contiguous region of memory. | ||
|
|
||
| ### Associated Item | ||
|
|
||
| An associated item is an item that is associated with another item. Associated |
There was a problem hiding this comment.
I'm okay with merging this, but this definition is a bit circular; we should figure out a better way to describe this.
There was a problem hiding this comment.
I'll do this as a part of Part 2.
src/items/implementations.md
Outdated
|
|
||
| Implementations are defined with the keyword `impl`. | ||
|
|
||
| ## Bare Implementations |
There was a problem hiding this comment.
Aren't these called "inherent implementations"?
There was a problem hiding this comment.
I've seen them called both. Inherent is probably a better name though. Will fix tonight.
src/items/implementations.md
Outdated
| Bare implementations associate the associated items to the implementing type. | ||
|
|
||
| The associated item has a path of a path to the implementing type followed by | ||
| the associate item's path component. |
There was a problem hiding this comment.
(review note, this is resolved below)
Trying to not focus on what it means to associate a type, nor deal too much with generic impls at this point.
|
Thanks! |
Trying to not focus on what it means to associate a type, nor deal
too much with generic impls at this point. Those will come in future parts.
Right now everything about associated types are defined in
items/traits.md. I didn't touch that here.Fixes #5. Albeit, I'm not a fan of the wording which I just pulled directly from the RFC.
cc @scottmcm for review.