Personally, I never accepted the annotation of "lifetimes" in Rust and I still think that we can do better. The average programmer should still work with _ref_ and _ptr_ and _var_ and the compiler will derive the "correct" reference types (abbr. _reft_ ) for the programmer.
> However, the original spec also mentioned introducing mutation type safety > much as Rust has in a set of rules: 1. Everything starts out "owned" as suggested above, meaning that Rust doesn't need an "owned" keyword as it is the default. 2. Owned things can be mutated by their owner only if there are no mutable references, implying in Nim terms that they can be "moved" only if there are no "mdangling" references and still can never be copied. 3. Owned things can still be mutated no matter how many immutable references there are; they just can't be destroyed, which is as per the specification. 4. There can be only one mutable reference to anything, and when there is one, owned references can no longer mutate as above. That said, I'd like to complete the "storage classes" aka "reference types" (abbr _reft_ ) with the following system: 1. For _owned refs_ , we have 3 lifetime levels, _orig_ , _xorig_ , and _xxorig_ . _xxorig_ is never visible for the programmer[1]. The library programmer will see and use _xorig_. If the head of a proc contains a _xorig_ , then this tells the compiler that the given reft has longer lifetime than every _orig_ passed in the head. 2. Read/Write rights are orthogonal to ownership. Ownership and R/W rights are different. 3. Option types will come to the rescue in special cases, but generally the compiler should infer the appropriate refts statically. 4. Even if something is defined with option types (the simplest one: nullable ptr e.g.) , the compiler keeps working with static analysis as long as possible. 5. refs/ptrs can be fields in a container(tuple,"object"). They have their refts (statically or dynamically) , but the surrounding container has its reft too. This leads to some kind of "viewpoint adaptation". 6. The refts evolve as states in a finite automaton. E.g, the typical "career" of an _orig_ looks like: _orig iso_ => _orig uni_ => _orig trn_ => _orig iso_. Where _iso_ stands for "isolated" : no other ptr points to the structure. _uni_ means "write uniqueness" (but another pointer points to the structure), with _trn_ another pointer might write into the structure, but transitionally. The _orig_ gets the _iso_ back when the other pointers have left the scope. Then, we have _mut_ : A pointer with reft _mut_ may write into the structure, but data only. The ptrs in the structure remain unaffected. I think that the proposed reference types are complete enough to remove lifetime annotations. Moreover, the state transitions can be inferred most of the time. [1] _orig_ in the proc head converts implicitly into _xorig_ , _xorig_ into _xxorig_.
