Hacker News new | ask | show | jobs
by pcwalton 3798 days ago
> Unlike Stroustrup, he acknowledged the existence of Rust but said the lifetime annotations are too verbose.

As far as I can tell, this was an incorrect claim. The ISO Core C++ lifetime elision rules aren't meaningfully more aggressive than Rust's. We could easily add more elision to Rust if it turned out to be necessary, but the cases in which ISO Core C++ has extra lifetime elision rules that Rust doesn't don't come up often enough to make a difference.

Lifetime elision is a double-edged sword anyway. It's somewhat controversial in the Rust community, because it's not reading the lifetime annotations that causes the cognitive overhead: it's the semantics and what the compiler will enforce. Having fewer lifetime annotations can actually make the code a lot more confusing. Based on experience, I would caution C++ to not go overboard with it: being able to show pretty code on slides is not worth confused and frustrated users.

1 comments

> It's somewhat controversial in the Rust community

We added a lint to clippy that detects places where you could rely on elision but don't. I'm particularly fond of it, because many Rust programmers (including me) still default to the pre-input-output rule regime by explicitly typing out `fn<'a>(&'a u8)-> &'a u8`. It's caught a lot of this and made code nice and clean.

However, we've have multiple people ask the lint to be off-by-default for input-output cases where one of the two sides has a struct/enum lifetime (`Foo<'a>`, not `&'a _`), because it's nice for that to be explicit. (At the same time, multiple people feel like it should stay)

We'll have to see what happens when we RfC the clippy defaults.