Lose the tick

[glaebhoerl]

Impact in tee minus...

[tshepang]

a discussion from last year in which no decision was made

[sinistersnare]

a similar RFC, which was rejected.

It is too close to 1.0 to change this IMO. I also do not like any of the proposed syntaxes for annotating references themselves.

-1. I like the thought that we should move to a more pythonic approach of using keywords over sigils, but i feel like this should stay. Thanks for the proposal :)

[tshepang]

another discussion

[blaenk]

I wouldn't mind this, I'd say I'm more or less indifferent. If we did do this though, I think the first syntax is by far the cleanest and nicest. The rest are steps back IMO. In fact, I think this syntax is pretty nice and would be cool if it were implemented, but I don't have high hopes given the previous rejected RFCs and the proximity to stable.

fn get_mut<lifetime a>(foo: &a mut Foo) -> &a mut Bar { ... }

Also, I personally don't mind the 'wordiness' of writing out lifetime, but I do think it may be an issue for other people, consider that it would be unique in that most other keywords are shortened (e.g. fn, pub, i32, etc.). If we could come up with a shortened version, it would cut down on the 'wordiness' of it while still being nice and clean, but I can't imagine what shortened version it would be that wouldn't also be nearly as confusing as ' alone. For example, lt would probably be too short as to defeat the motivation of this RFC, the alternative shortest I can think of is life but that does away with the second and important word, though personally I would be perfectly fine with both.

The unmatched ' alone, like you said, is enough to trip up newcomers; at least lt and life would be easily searchable and looked up.

Over the course of writing this I've made up my mind. I do think this change would be pretty nice, preferably if it were a shortened form of lifetime which I imagine would also serve to be less friction when updating all existing code (even if most people would use search/replacers, I can already imagine people complaining that their code size exploded when going ' -> lifetime).

[Ericson2314]

I would prefer a: lifetime or something, for forward compatibility with HKT. Otherwise looks good. Like keeping the &mut together too.

[nikomatsakis]

Regardless of the merits of the proposal, I think it comes too late. We can't go changing fundamental parts of the syntax right now.

[AndyShiue]

I prefer ~a than 'a or lifetime a because a single ' looks strange and I don't want to type an 8-character keyword, but anyway, it's too late to change ...

[netvl]

-1 for all of the reasons already stated in earlier discussions and because it is too late.

[mahkoh]

The ' sigil on lifetimes is, for newcomers to the language, visual noise with little discernible meaning. The unmatched quote is also extremely unnatural for those accustomed to C-style syntax: our main target audience. (Some of the author's more knowledgeable friends, acquainted with functional programming languages and not only C, have expressed the sentiment that they find it weird, and always reflexively want to insert the closing quote.) The rest of Rust's syntax does a fantastic job of fitting new concepts into a familiar C-style syntax in an intuitive wayl; it's only the ' sigil on lifetimes which sticks out like a sore thumb and breaks the metaphor.

The new syntax with the lifetime keyword is more explicit, meaning it is more verbose and provides greater clarity. Considering that due to excellent lifetime elision, explicit lifetime variables are infrequently required, and that lifetimes are a concept not to be found in any other popular language, this seems like an obviously worthwhile tradeoff.

From http://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2014/Keynote

[glaebhoerl]

Yes, it's too late. We should do it anyways. Better late than never.

Rigid adherence to self-imposed deadlines is just a way to avoid having to rationally weigh the costs and benefits.

The question should only be: is the time and effort to make the change worthwhile in light of the future benefits? I think the answer to that question has always been "yes", and if so, then it still is.

[nagisa]

I’m perfectly fine with a tick and have come to like it, even. 👎

[glaebhoerl]

It should be gotten rid of not for your sake or mine, but for the legions of C/C++ programmers' who have yet to encounter the language.

(I, personally, can survive the ticks as well.)

[sinistersnare]

I think @mahkoh's image is perfect, I have come to like the tick syntax, its simple and understandable. I dont like arguing syntax much, so thats all I want to say :)

[gulbanana]

aesthetically, sure, get rid of it. it doesn't seem important enough to spend much effort on but if we happen to live in a perfect world then yes, a keyword seems a bit nicer.

[marton78]

+1 For readability and searchability. Better late than sorry!

[quantheory]

👎

I question the pedagogical benefit of removing the tick. (In fact even as a C++/Python-er I feel the opposite way.)

When starting to learn Rust, I always thought that the ' was much more clear than a long keyword, because it reduces visual clutter while still standing out. It also makes lifetimes and types easier to distinguish when actually used.

It only took a minute to learn what the tick means, and it was hard to forget because it appears everywhere. I just don't think that something used so frequently needs a mnemonic keyword.

[breckinloggins]

Is there a higher-level abstraction that, if considered, would make the lifetime keyword useful semantically as well as syntactically?

In other words: could fn get_mut<my_custom_construct a>(foo: &a mut Foo) -> &a mut Bar { ... } ever mean anything cool?

Other possible keywords: lives, live, scope (cool but wrong, unfortunately), life (as mentioned)...

+1 on &mut{a} or even &mut<a> (if possible). I personally find the &mut -> &a mut separation odd. Another option is &mut(a), which is less "pointy".

This is way out there, but could we possibly get rid of the pre-declaration altogether? In other words, just have fn get_mut(foo: &mut(a) Foo) -> &mut(a) Bar {...} and simply declare that all lifetime names in the same (module/crate/whatever) with the same name are equal. I don't know the grammar well enough to know if this is even coherent, but it's an interesting idea.

Finally, I'd like to echo the point that though this would not be a convenient time to change this syntax, if we had a time machine we might visit the future and discover that it was the only time we could have done it.

[glaebhoerl]

In other words: could fn get_mut<my_custom_construct a>(foo: &a mut Foo) -> &a mut Bar { ... } ever mean anything cool?

Yes, though not as a lifetime. See my reddit comment about kind ascriptions I linked from the motivation section.

[Ericson2314]

On a related note, since <T: Trait> isn't deprecated by where clauses, what will kind annotations look like?

[glaebhoerl]

http://www.reddit.com/r/programming/comments/2ny8c1/rust_generics_and_collections/cmiqhyx that's my idea

[Ericson2314]

Hmm, that works. To play devil's advocate, If you use ' and type, and allow dropping the type in the <type T> case, <'a> falls right out of those rules. Of course <type<', ', type, '<'>> Q: Foo> is also the most unappealing syntax ever, so the devil better get a new advocate.

[nrc]

We discussed this at today's triage meeting. The overall feeling was that it is simply too late to make this kind of significant change, especially as there would be lots of discussion and probably a fair bit of design work/ironing out bugs.