[lang-team-minutes] Elision 2.0

[mgeisler]

As a new user of Rust, I would like to say that I find foo<', T> very very unfortunate. Try reading it without the monospace font: foo<’, T>. The symbols are dancing around on the baseline… is it a speck of dust? or is it an apostrophe? Also, the apostrophe followed by a comma almost looks like a ;.

This kind of syntax is anything but elegant and moves Rust more towards the line-noise camp of languages — I’m a Python guy, so lots of special characters and symbols are not “elegant” to my eyes I feel code should be optimized for readability since it’s normally read by many more people that the person who writes it.

Do I understand it correctly that the proposal simply allows the programmer to use ' instead of 'a when there is just one lifetime? If so, please just keep the more explicit syntax. Explicit is better than implicit, and all that, as they say in the Python world

There is some precedense for using 'foo in programming languages – Lisp use that syntax for its atoms. It’s pretty readable even though apostorphes are normally attached to the end of a word. But a free floating apostrophe? Please don’t.

[arielb1]

I always imagined it as the lifetime of the reference itself, but of course many people confuse it with the lifetime of referent (the resource being referenced), and this seems obvious in retrospect.

I’m not sure how bad of an idea that is - accessing the referent through a reference after the references lifetime is over is sketchy and probably UB. So from the point of the “callee” the lifetime of the reference is all that matters.

Of course there’s also the confusion that occurs because “values” of the kind lifetime can never be actually observed (because they are “erased” before run-time), so you must always work on some kind of abstract level.

[nikomatsakis]

So, at this point, I would like to go and update the Elision 2.0 RFC draft. I feel like we’ve got a lot of resolution on most issues except for the syntax. I think there are basically three four contenders here:

Foo'     Foo'<T>
Foo<'>   Foo<', T>
Foo<&>   Foo<&, T>
Foo<ref> Foo<ref, T>

I see the advantages and disadvantages as being roughly something like:

• the tick ('): similar to 'a, but can be surprising on its own
• the ampersand (&): similar to &T, doesn’t “lead you” to 'a notation, perhaps surprising on its own
• the keyword (ref): not a sigil, but doesn’t “lead you” to 'a; maybe works best if we migrate away from 'a and towards <ref a>, but then it does sort of sound like a value, not a lifetime

I like that Foo<ref> basically means “a struct with references inside of it”, though, that seems…like something we could explain.

UPDATE: I added Foo' after the fact. I had originally left it out, but I think it’s too early to rule it out.

[phaylon]

I would add:

• for <'>: Consistent with current lifetimes, free of any current meaning. Kind of implies that it can apply to multiple lifetimes (' with a name refers to a specific lifetime, without a name can refer to many.
• for <&>: Currently read as a borrow operator. Inconsistent with individual lifetimes (a single 'a can apply to multiple references (or none, if it’s about phantom data, but the & operator usually used for specifying individual borrows now implies multiple (or none).
• for <ref>: Has current different meaning for bindings. Requires language changes with big impact to become consistent. Like & it currently doesn’t imply multiplicity.

I also feel “a struct with references inside it” is actually the wrong reading. I like that it currently communicates that it is generic over a lifetime, because they are important outside of types outright containing references. There’s types just being generic over references via phantom data, there’s trait objects, there’s HRTB, which I believe should be included in the evaluation.

[repax]

Another possibility is: Foo<'_>

(has some lifetime constraint)

[glaebhoerl]

the ampersand (&): similar to &T, doesn’t “lead you” to 'a notation,

It occurs to me that & and ' have kind of opposite advantages. We can look at it in terms of what things a function signature involves:

&/&mut and elided lifetimes <-> user types and elided lifetimes <-> explicit lifetimes

where the middle case is the one we’re trying to find syntax for, and the other two are known quantities. Then Foo<', T> is consistent with the logic of explicit lifetimes, with respect to what symbol to use and where to put it. Meanwhile, Foo<&, T> is consistent with the logic of elided signatures with & and &mut, with respect to what symbol to use and where elision happens. That is, the existing syntax for elision with & and &mut, as well as the syntax extended with Foo<&, T>, both follow a simple rule: elision happens where there is an & symbol without a specified lifetime.

In other words, the ampersand & leads you from elided lifetimes with built-in types (&, &mut) to elided lifetimes with user-defined types, while the tick ' leads you from elided lifetimes with user-defined types to explicit lifetimes.

Purely logically speaking I find both of these roughly similarly compelling; the deal-breaker for me is really just that I find Foo<', T> to be an incredibly big eyesore and Foo<&, T> merely a normally-sized eyesore.

@mgeisler (and everyone else who liked their comment), what do you think about Foo<&, T>? Obviously it’s not ideal either, but I find it considerably less “lexically offensive” than Foo<', T>; I’m not sure whether I’m representative.

[zackw]

Foo<'>   Foo<', T>
Foo<&>   Foo<&, T>
Foo<ref> Foo<ref, T>

Here’s a still-relatively-new-to-the-language, haven’t-done-anything-fancy-with-lifetimes opinion: I find Foo<'> no worse than Foo<'a>, but I dislike both of them, because twenty years of C, shell, and Python have trained me to expect U+0027 to be an open quote, so my eyes automatically scan for the close quote and when it isn’t there there’s a sort of mental jar as I remind myself that this is not a syntax error in this language. (It doesn’t help that U+0027 is also used to introduce character literals, and is balanced in that context.)

I deeply dislike Foo<&>, because that should mean something to do with references, not lifetimes. This is again twenty years of C, or more precisely C++, where you might write template <typename T> struct Foo<T&> { ... } to specialize on reference-to-T. Yes, the ampersand is on the other side of the T there; it’s still even more of a mental jar than the unbalanced single quote.

Foo<ref> … well, again, that keyword should mean something to do with references, not lifetimes, but I don’t have such deeply ingrained associations for ref because it’s only a keyword in Rust, and you only use it inside patterns. Recycling it to mean something to do with lifetimes in this context is only about as bad as the many different meanings of static in C++; I could get used to it.

What about #? I don’t think that’s used for anything in this language yet, and #a actually looks like a symbol rather than an unbalanced string constant.

[nikomatsakis]

I deeply dislike Foo<&>, because that should mean something to do with references, not lifetimes.

I’m not 100% sure what you mean by this. I think lifetimes have a lot to do with references. In fact, part of what I find appealing about Foo<&> is precisely that it brings references to mind. So I’m trying to understand just what it is that is so jarring – is it because you expect that to mean "reference to Foo"? (That is sort of how i interpreted the rest of your comment.)

[zackw]

I expect Foo<&> to be something not entirely unlike “the variant of Foo that applies to immutable borrows of some unspecified type”. I expect it to be in contrast to Foo<> which is the variant applying to moves of some unspecified type, and Foo<&mut> the variant applying to mutable borrows. Maybe it only makes sense to write these things with a concrete type, or at least a trait bound.

I don’t feel that I fully understand lifetimes, but in my head lifetimes are a property of objects, not references. Foo<'a> is an object with lifetime 'a, and the most obvious reason you bother writing that is because it internally refers to some other object and you want the compiler to ensure that that object’s lifetime is as least as long as 'a, but there are other reasons; for instance, perhaps it is only valid while a lock is held, but it doesn’t refer to the lock itself.

[sanxiyn]

I don’t feel that I fully understand lifetimes, but in my head lifetimes are a property of objects, not references.

In Rust, lifetime is a property of references, not objects. Foo<'a> is not an object with lifetime 'a. Such understanding is precisely what (I think) we are trying to prevent.

[petrochenkov]

I’ve seen much more complaints about Rust’s ugly noisy syntax with lifetimes than about lifetime elision in user-defined types (e.g. S<'a> => S) being confusing. So, I think I agree with points from @glaebhoerl’s list that suppose that maybe S => S<'> is trying to solve a non-problem (or at least not-sufficiently-large problem). At the same time

struct S<'a> {
    field: &'a u8
}

=>

struct S {
    field: &u8
}

certainly solves a real problem.

It would be also very nice if adding/removing a field with lifetime to/from a struct wasn’t as “viral” as it is now, requiring adjusting dozens of other places where S is used. Look at what people do to avoid the churn. The S => S<'> change seems to make it worse.

[jnicklas]

Does this mean the Foo' syntax is out? To me it looks by far the nicest, and so far no one has objected to it from a technical standpoint.

Foo'     Foo'<T>
Foo<'>   Foo<', T>
Foo<&>   Foo<&, T>
Foo<ref> Foo<ref, T>

[zackw]

In Rust, lifetime is a property of references, not objects. Foo<'a> is not an object with lifetime 'a

I did make a mistake: what I should have said is "Foo<'a> is an object whose lifetime is constrained to be shorter than 'a, whatever 'a is". But I simply cannot wrap my head around the notion that “lifetime is a property of references, not objects.” References are a subset of objects. It has to make sense to talk about the lifetime of an arbitrary object.

[leodasvacas]

I’m personaly feeling skeptical of annonymous lifetimes. Anything that is not <'> is inconsistent with how explicit lifetimes are used. Elision is simple and beautiful and forms a nice mental model because it just removes stuff from the explicit form, that is kept in <'a> to <'>. When doing <'a> to <&> you swap a symbol for the other which seems arbitrary. But <', T> is just symbol spaghetti.

This is what I think things should look like:

fn foo(x: &i32, s: &str) -> Foo<'s>

I think we should back off from annonymous lifetimes and explore “parameter name instead of declaring a lifetime”.

[Nemo157]

Just “parameter name instead of declaring a lifetime” doesn’t help with declaring a struct containing lifetimes or writing impl blocks for it (although, re-reading the OP and very briefly scanning the thread I don’t see that mentioned at all).

What might be useful is to separate discussion of the two proposals, they seem to be mostly independent of each other (other than the fact they’re both aiming to help “make the ‘easy things easier’ in the lifetime system”). And I think having a shorthand for declaring and referring to an existing anonymous lifetime is less controversial (and less bikesheddy) than adding new syntax for explicitly anonymising existing named lifetimes.

---

Expanding the idea I had about allowing the “anonymous” syntax to be used in impl blocks, I think it would be consistent to allow using the anonymous lifetime marker in an inherent impl block or an impl Trait for block where Trait does not contain any lifetimes itself, e.g.

struct Foo<'a>(&'a [u8]);

impl<'a> Foo<'a> {
    fn new(buf: &[u8]) -> Foo {
        Foo(buf)
    }

    fn get(&self, i: usize) -> Option<&u8> {
        self.0.get(i)
    }
}

impl<'a> AsRef<[u8]> for Foo<'a> {
    fn as_ref(&self) -> &[u8] {
        &self.0
    }
}

could be rewritten as (using the <'> contender as that’s my preferred choice out of what’s been proposed so far)

struct Foo<'>(&[u8]);

impl Foo<'> {
    // Note that this is closer to writing
    //     fn new(buf: &[u8]) -> Foo<'a>
    // above, which currently results in "expected Foo<'a>, found Foo<'_>"
    // Hopefully it would be allowable to unify anonymous lifetimes and have this work as expected
    fn new(buf: &[u8]) -> Foo<'> {
        Foo(buf)
    }

    fn get(&self, i: usize) -> Option<&u8> {
        self.0.get(i)
    }
}

impl AsRef<[u8]> for Foo<'> {
    fn as_ref(&self) -> &[u8] {
        &self.0
    }
}

There may be some scope for expanding this to some cases of Trait containing lifetimes, but I can’t think of what cases those would be right now.

[leodasvacas]

Just “parameter name instead of declaring a lifetime” doesn’t help with declaring a struct containing lifetimes or writing impl blocks for it

Good point. For struct declarations I don’t think elision buys much. For impls headers we could keep the current (unimplemented) elision rules which say that impl<'a> Foo<'a> becomes impl Foo. Requiring even an annonymous lifetime for a struct in input position is excessive I think.

[nikomatsakis]

I don’t feel that I fully understand lifetimes, but in my head lifetimes are a property of objects, not references. Foo<'a> is an object with lifetime 'a,

This was really helpful for me to better understand your point of view. I am trying to decide what I think about it and what implications it has for syntax. =)

I think there are many times when it is legit to view “reference” as a broader category than just the &T type – e.g., the Ref<'a, T> returned by a RefCell is kind of a “reference”. This seems to fit into the mental model you describe here, though you are using the word reference more narrowly.

There are some other use cases where I think the best thing is to think of Foo<'a> as a “struct with references in it”. This is particularly true when you have multiple lifetimes. In the compiler, for example, we have a number of “context” structs that look like Context<'a, 'tcx> or something like that. In this case, the context collects a number of references pointing at data that lives at various points on the stack, and those multiple lifetimes let us distinguish those cases. (e.g., the data with lifetime 'tcx lives in an enclosing arena, whereas the 'a data tends to be some fleeting references like the duration of a loop).

It is certainly true that it is possible to have structs with lifetimes that fit into neither of those cases, on a technical level, but generally I feel like there is still a “reference” conceptually. e.g., the Guard<'a, T> that is returned by locking a lock (to use your example) is basically a reference with lifetime 'a that points at data protected by a lock (I think in fact that it probably holds a reference to the lock itself, but you could perhaps imagine that it might not).

[krdln]

In Rust, lifetime is a property of references, not objects. Foo<'a> is not an object with lifetime 'a. Such understanding is precisely what (I think) we are trying to prevent.

References are a subset of objects. It has to make sense to talk about the lifetime of an arbitrary object.

I think that what @sanxiyn meant was that lifetimes are properties of references (as types), not objects (values). I this meaning, references, which are types are not subset of objects, which are values.

Foo<'a> means that Foo probably contains somewhere a reference &'a X, which points to object (of type X) that outlives* the lifetime 'a. This 'a is property of the type (eg. Foo<'a>) which limits the set of values, which it can point to. So basically, Foo<&> would mean “warning: Foo contains some references”.

*) In some sense, the value also has a lifetime (the span of time it’s alive), but it’s not what the lifetime in 'a notation means.

[nikomatsakis]

I’ve seen much more complaints about Rust’s ugly noisy syntax with lifetimes than about lifetime elision in user-defined types (e.g. S<‘a> => S) being confusing. So, I think I agree with points from @glaebhoerl’s list that suppose that maybe S => S<’> is trying to solve a non-problem (or at least not-sufficiently-large problem).

Different parts of this proposal have distinct motivations. My feeling remains that it is important that we make the notation light but not too light, and this is reflected in the collection of proposals here. I guess that the meaning of light is obvious (less to type) but let me elaborate a bit on “not too light”.

I think it is really helpful to have a consistent, lightweight visual cue that indicates when lifetimes are present. I am not necessarily targeting “beginners” here (though I think it may help there); I am also thinking of advanced users. That is, I really appreciate being able to quickly scan type signatures and figure out which structs contain embedded references and which do not, as well as to identify when the return type may “extend” a borrow and when it will not.

I agree that people are not requesting Foo<'> in argument position (well, I don’t really know, but I can believe that). I do not necessarily think this means it would not be helpful to them. That is, I think that having a consistent visual cue could well help people to get a better understanding of how lifetimes work.

Note that it is easy to take this too far! As I’ve mentioned before, in Ye Olden Days of Rust, we allowed you to elide lifetimes everywhere. We even went so far as to infer whether a struct might have references in it globally. This was mega-confusing. You would get wacky errors and have to trace though layers of type definitions to figure out what was going on. The reaction to this was to make all lifetimes named and explicit. I see the elision proposal (and this one) as part of an ongoing effort to step back from that and figure out just the right places to make lifetimes explicit (or semi-explicit).

It would be also very nice if adding/removing a field with lifetime to/from a struct wasn’t as “viral” as it is now, requiring adjusting dozens of other places where S is used.

I agree it’s annoying to have to adjust trait signatures, but I am not convinced that the right solution is to allow you to obscure the fact that lifetimes are present. I do think there is a need to make it possible to code that is more tolerant of how many lifetimes are present. For example, one scenario that we don’t have a solution for just now is that sometimes I want to specify just some of the lifetimes on a type.

In the compiler, this often comes up when I want to specify 'tcx (the “big” lifetime that is often floating around) but I don’t care about the 'a (the “transient lifetime” that often shows up):

impl<'tcx> Foo<'tcx> {
    fn bar<'a>(tcx: TyCtxt<'a, 'tcx>) -> Ty<'tcx> { ... }
    //     ^^              ^^
    // it is annoying that I have to give `'a` a name here
}

I think a good convention (which we have not consistently adopted in the compiler; I’ve debating about refactoring things so that we do) is to list lifetimes in “increasing” order. So e.g. it’d be TyCtxt<'a, 'tcx, 'gcx> ('a is transient, 'tcx is the current inference session, and 'gcx is the global compilation session). In that case, I think that you almost always just want to specify a suffix of the lifetimes. So you could imagine some scheme that lets you elide “leading” lifetimes. But it’s kind of … wacky. '_ helps here but I’m not keen on it otherwise.

Anyway, leaving all that aside, I feel like another potentially good solution to the problem of having to refactor types is that IDEs should be able to do this refactoring. I know that’s sort of dodging the question, but in my view there is a real readability tradeoff here. (Alternatively, of course, you could say that IDEs can add visual indicators when references might be present.)

[nikomatsakis]

So, the original elision RFC actually specified that one should be able to elide lifetimes in impls, but it was never implemented. I’ve been meaning to write up mentoring instructions for some time. I definitely agree we should permit that. However, there is one aspect of your post that I’m not sure about:

impl Foo<'> {
  fn new(buf: &[u8]) -> Foo<'> { .. }
}

I would have expected the Foo<'> here to expand to the lifetime of the buf parameter. So basically fn new<'a>(buf: &'a [u8]) -> Foo<'a> {... }. As it happens, this would probably work out just fine in this particular case, but it is a distinct lifetime from the one that decorates the impl, and in some cases that might matter.

It’d be sort of nice if we had a way to “refer” to the lifetimes in the impl without declaring them. One thought that has been bandied about from time to time is having some ability to “declare” lifetimes and types in the impl header in a more lightweight way. For example (not an actual proposal):

impl Foo<let 'a> { // equivalent to `impl<'a> Foo<'a>`
    fn new(buf: &'a [u8]) -> Foo<'a> { ... }
}

One could then also do things like impl Option<let T> instead of impl<T> Option<T>. Kind of a “crazy cross-cutting proposal”, though, and obviously introducing a new convention here would affect a lot of code (also, I feel like to do this right, we would want the type/trait declarations to match, so one would write enum Option<let T>).