Skip to content
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

In-band lifetime syntax inconsistency? #37

Closed
HadrienG2 opened this Issue Jun 23, 2018 · 5 comments

Comments

Projects
None yet
3 participants
@HadrienG2
Copy link

HadrienG2 commented Jun 23, 2018

In the in-band lifetime section, the following syntax is introduced:

fn two_args(foo: &Foo, bar: &'bar Bar) -> &'bar Baz

Later, in the lifetime elision in impl section, it is said that the feature interacts with in-band lifetime syntax in the following way:

fn bar(&self, arg: &str) -> &'arg str

There is a little difference between these two syntaxes, however. The former syntax gives the impression that the lifetime parameter is named "bar" by choice, but could be anything, whereas the latter syntax gives the impression that one can use &'arg as a shorthand to denote the lifetime of reference argument "arg" of a function.

Which syntax is the correct one?

@Nemo157

This comment has been minimized.

Copy link
Member

Nemo157 commented Jun 23, 2018

The RFC itself appears to be inconsistent. The summary and guide level explanation use the first form (lifetimes must be introduced as part of the arguments, and don't have to use the same name) while the reference level explanation use the second form (lifetimes with the name of an argument binding implicitly refer to that binding).

Testing the feature seems to show that only the first form works.

@HadrienG2

This comment has been minimized.

Copy link
Author

HadrienG2 commented Jun 23, 2018

I guess this ambiguity is one thing to be sorted out before the feature lands, then :)

@Nemo157

This comment has been minimized.

Copy link
Member

Nemo157 commented Jun 23, 2018

Opened rust-lang/rfcs#2486 to fix the RFC and #38 to fix the docs.

@steveklabnik

This comment has been minimized.

Copy link
Member

steveklabnik commented Jun 25, 2018

Gonna wait to see what the lang team says before merging this.

@steveklabnik

This comment has been minimized.

Copy link
Member

steveklabnik commented Jun 25, 2018

actually, we should probably take the other PR as it was first...

@aturon aturon closed this in #38 Jun 25, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.