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.