Blog Post: Lifetime Parameters in Rust

Back on the topic of lifetime parameters, others have mentioned that an optional GC might still be under development for Rust and also we have the Rc / Arc alternatives. It just occurred to me that if we will want to mix GC / Rc / Arc instances in the same function, then the problem is that the functions we call which take these instances as inputs may already be annotated with lifetime parameters. In other words, I am thinking the lifetime parameters annotations compel the annotated functions to be used only with compile-time managed lifetimes. Unless i am missing something in my understanding, it seems annotation kills the ability to intermix and infects the code every where.

I am thinking that for much of my code I am likely to end up using a well designed generational GC{1} most of the time, and use only borrowed function arguments{2} infrequently in cases where it is very non-convoluted for the compiler to manage the resource lifetime, especially where temporary objects can be optimized. Because I am guesstimating (but I might be wrong) that with good design control over the creation of temporary objects with a very well design generational GC, then perhaps most of the claimed memory consumption versus performance tradeoff disappears{3} and thus I can't justify adding complexity to code for very little gain{4} (because afaics it is a loss in the overall scheme of costs and goals of open source). Thus I am beginning to wonder if tracking lifetimes from inputs to outputs might be an unnecessary pita in the overall appraisal. I am not arguing to change anything in Rust as others (and this community) may have other priorities/preferences/use cases. I am just wondering if anyone can present a cogent rebuttal which might cause me to realize I am very wrong to think down this line of pondering.

So I am thinking borrowing everywhere (actually lifetime checking off) by default (no moves and no annotations), no lifetime annotations, and only using compile-time checked resource lifetimes in simplest of scenarios. Radical thought.

Edit: there would still need to be an annotation on an input argument that should be a compile-time enforced borrow (or alternatively on input arguments which should not have enforced borrow) and on a let that requires a compile-time enforced lifetime.

Curious if anyone can show me that it is short-sighted. I am trying to find some reasonable simplification, because the thought of ever more complex annotations on typing functions and needing to create superficial scopes to enable one to have two mutable references to portions of the same object, feels intuitively to me as a step backwards or sideways in the evolution of programming languages. But of course, I am probably wrong. Devil is in the details, not just intuition.

And note, apparently I could use Rust and just stick with my desired usage pattern, as one of my options. Perhaps I could even write a parser that outputs to Rust and enforces my desired defaults (although this might get unwieldy). I am just considering all my options, and first I need to rationally figure out what I really want and why.

Edti#2: impacting my thought process is the assumption I have that Rust's compile-time lifetime checking isn't going to work in a majority of the cases, e.g. multiple mutable references to elements in collections. Thus I am thinking we end up with lifetime parameters on 80% of our functions, for a feature we can't employ 80% of the time. Maybe I am wrong about the relative percentages. And upthread discussion didn't seem to declare Rc / Arc as a clear winner over GC for the other cases.

{1} [quote="shelby3, post:2, topic:5737"]
V8 is already doing this apparently:

A tour of V8: Garbage Collection —
Write barriers: the secret ingredient

{2} [quote="shelby3, post:2, topic:5737"]
Correction: the lifetimes of the iterators are not encapsulated if they can leak into the outputs of the pure function. I assume such could in theory be prevented by a compiler by annotating the constraint on the inputs that their references can only be borrowed. Well so we can model this with Rust's lifetimes and as stated GC wouldn't be needed. So seems I've found a use case for Rust's lifetimes, but note it is a special case and not substituting for GC in general. And so far this has not identified a need for moves.


{4} Why Haskell matters - HaskellWiki
When Haskell is Faster than C | Hacker News (When Haskell is Faster than C)