Skip to content

include description of bindings in the reference #654

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.

Sign up for GitHub

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

Open
wants to merge 4 commits into
base: master
Choose a base branch
from
Open

include description of bindings in the reference #654

Changes from all commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
6d53466
include description of bindings in the reference
nikomatsakis Aug 15, 2019
d91c440
Update src/lifetime-elision.md
nikomatsakis Aug 16, 2019
24b5d40
add periods to bullets
nikomatsakis Aug 16, 2019
d1413e4
reformat link
nikomatsakis Aug 16, 2019
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
34 changes: 32 additions & 2 deletions src/lifetime-elision.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -71,9 +71,17 @@ rules.
If the trait object is used as a type argument of a generic type then the
containing type is first used to try to infer a bound.

* If there is a unique bound from the containing type then that is the default
* If there is a unique bound from the containing type then that is the default.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
* If there is a unique bound from the containing type then that is the default.
* If there is a unique lifetime bound from the containing type then that is the default.

* If there is more than one bound from the containing type then an explicit
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
* If there is more than one bound from the containing type then an explicit
* If there is more than one lifetime bound from the containing type then an explicit

bound must be specified
bound must be specified.

If the trait object is used as a binding for an associated type (e.g.,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure the "e.g." parenthetical is useful here. But if we keep it, it should say "for example". It'd be nice if "trait object" and "associated type" were links. Or link to the full example?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, perhaps the e.g. isn't the most elegant way to express it, but I think that showing the syntax will go along way towards helping people understand what the other words actually mean.

I can definitely make links.

Separate but relevant: In general, I tend to think we should deprecate the term trait objects and move towards "dyn types" or something like that, but that'd be a shift obviously. I do think though that leveraging the keyword in our terminology makes a lot of sense.

`Item = dyn Trait`) then the containing trait is first used to try to
infer a bound, in an analogous way to type arguments:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
infer a bound, in an analogous way to type arguments:
infer a lifetime bound, in an analogous way to type arguments:


* If there is a unique bound from the containing type then that is the default.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
* If there is a unique bound from the containing type then that is the default.
* If there is a unique lifetime bound from the containing type then that is the default.

* If there is more than one bound from the containing type then an explicit
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
* If there is more than one bound from the containing type then an explicit
* If there is more than one lifetime bound from the containing type then an explicit

bound must be specified.

If neither of those rules apply, then the bounds on the trait are used:

Expand Down Expand Up @@ -129,6 +137,27 @@ struct TwoBounds<'a, 'b, T: ?Sized + 'a + 'b>
TwoBounds<'a, 'b, dyn Foo<'c>>
```

Here is an example featuring associated type bindings:

```rust,ignore
trait Bar<'a> {
type Item1: ?Sized;
type Item2: ?Sized + 'a;
}
trait Baz { }

dyn Bar<
'x
Item1 = dyn Baz, // defaults to `dyn Baz + 'static`
Item2 = dyn Baz, // defaults to 'dyn Baz + `x`
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a great and more complicated (which is why it is great) example to include as a test in the PR!

>
```

**Note:** As of this writing, the rules for associated type bindings
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"As of this writing" is redundant.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, this phrase suggests a temporary condition that is expected to change. It doesn't feel redundant to me.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
**Note:** As of this writing, the rules for associated type bindings
**Note:** As of 2019-08-16, the rules for associated type bindings

are implemented incompletely, and explicit bounds may sometimes be
required when they ought not to be. See [rust-lang/rust#63618] for
more details.

## `'static` lifetime elision

Both [constant] and [static] declarations of reference types have *implicit*
Expand Down Expand Up @@ -175,5 +204,6 @@ const RESOLVED_STATIC: &dyn Fn(&Foo, &Bar) -> &Baz = ..
[function pointer]: types/function-pointer.html
[RFC 599]: https://github.com/rust-lang/rfcs/blob/master/text/0599-default-object-bound.md
[RFC 1156]: https://github.com/rust-lang/rfcs/blob/master/text/1156-adjust-default-object-bounds.md
[rust-lang/rust#63618]: https://github.com/rust-lang/rust/issues/63618
[static]: items/static-items.html
[trait object]: types/trait-object.html