subtask of RFC 195: implement associated lifetimes

[pnkfelix]

As a subtask of #17307, we want to implement associated lifetimes at some point.

This blocks the code revisions implied by #17828.

@aturon notes here that this may block 1.0; or at least, we certainly cannot mark libraries associated with #17828 as stable, so the real question is whether such library types need to be stable for 1.0.

[aturon]

To be clear, there's a P-backcompat-lang issue here: the design intends that lifetimes cannot be used in input position, only in output (associated item) position.

The rationale is that the arguments to a trait are used to drive dispatch; each different set of instantiations can provide a distinct implementation for the same Self type (as if they were different traits). But selecting an impl on the basis of a lifetime doesn't make any sense.

I would say this is P-backcompat-lang, but not necessarily 1.0 -- but we should discuss.

[pnkfelix]

Assigning P-high, not 1.0.

[japaric]

Assigning P-high, not 1.0.

Shouldn't we at least reserve the lifetime keyword before 1.0?

[apasel422]

Is there any plan to move forward on this? It doesn't appear that the lifetime keyword was reserved.

[aturon]

@apasel422 I don't know of any concrete plans, though a PR would be welcome.

In terms of keyword reservation, this can likely be handled via "contextual keywords".

[apasel422]

@aturon Thanks. Do you know how associated lifetimes will be referenced? The RFC doesn't appear to depict that syntax.

trait Foo {
    lifetime b; // or is this supposed to be `lifetime 'b;`?
    fn foo(&'Self::b self); // unsure if this is correct
}

[aturon]

@apasel422 You're right -- the RFC is incomplete on these points. I suspect we'd want a ' in both locations. Probably any implementation should be paired with an amendment to the RFC detailing this syntax (which can then be approved via the normal community process).

[apasel422]

By the way, this issue should be renamed to "subtask of RFC 195", not 59.

[brson]

Is this ever going to happen? P-low? Should this be B-RFC-approved to indicate that it's for completion of an RFC?

[nikomatsakis]

Switching over to lang team; my feeling is that I'd like this to happen, but I also sort of feel like a fresh RFC might be a good idea. Certainly I want this regularly when I have some "meta-parameterization" that is just a bundle of associated types (e.g., trait GraphTypes { type Node; type Edge; ... }, and everything has <G: GraphTypes> so they can name G::Node etc.

[nikomatsakis]

I know @pnkfelix and I have also talked about uses for this.

[nikomatsakis]

Anyway, P-low for sure.

triage: P-low

[nikomatsakis]

But I'll leave as nominated to discuss question of whether to have a new RFC.

[aturon]

@nikomatsakis Why do you think a fresh RFC is needed? Offhand it doesn't seem like there's a ton of wiggle room in the design space; the feature has just never been high enough priority to bother implementing it.

[nikomatsakis]

@aturon well, for example, the existing RFC gives zero examples of using an associated lifetime; based on a quick read, I didn't see an obvious syntax for how you name such a lifetime (is it &T::'x Foo? &'T::x Foo?). There seem to be parsing implications that are probably fine but I haven't fully thought through... (is it ok that we don't know if this is a path that leads to a lifetime until later? probably, but it makes the grammar quite a bit more complex I guess)

[aturon]

@nikomatsakis Got it, thanks.

Given those gaps, I'd be fine closing this out and requiring a fresh RFC to flesh it out and motivate it more substantially.

[nikomatsakis]

Closing because it needs an RFC.