Short lifetime, opposite of 'static?


#1

is there (or could there be) a way of marking a reference to specify ‘this lifetime can’t be assumed to be any longer than the passing scope’, i.e “the shortest possible lifetime” - use case being temporaries passed into functions ; (I gather the default assumptions revolve around 'self)

  • “shortest” '??? 'temp ?
    - e.g. minimum lifetime, for function arguments only.
    - any function body may not cache or return these references, only pass inward to sub-calls and copy in locals.
    - any use in structs would be similar: structs with “shortest lifetime” references would only exist to batch passed arguments

  • “quite short” 'self
    - already handled by Rusts existing defaults
    - e.g. collection accessors, may be returned to a caller e.g. foo[i]
    - but usually doesn’t escape the callers scope
    - common shortcut in the middle ground,

  • “middle ground”
    - returnable references that come from any function inputs
    - specific naming is unavoidable, most complex case.

  • “longest” 'static
    - ‘no references to worry about’
    - could persist for the length of the entire program
    - any pointers held by outputs are owned hence managed by the destructor

The hope is a combination of default ('self assumption), 'shortest, 'static could dramatically reduce the number of cases that you need to name specific lifetimes; most of my present thinking for return values is in the two cases (‘accessors’ and 'static … the returned value is either temporary, or can persist);

sometimes (e.g passing temporary lambdas) i’ve found myself needing to name temporaries, despite the intent of the use-case being simple; if there was a way to directly state the intent, it might streamline use further.

Another way to express part of the intent of ‘shortest’ and ‘longest’ is the idea of ‘no-escape’ : in both cases, the key idea is that no input references will escape the function call. In the case of ‘static’, any data passed in would have to be cloned (and owned) for return.

I am happy with rusts default 'self assumption, I think this choice handles the case of ‘accessors’ very well.


Borrow/move/closure symantics are driving me to my wit's end
#2

Check out this related internals thread. This one is different from your formulation in that it would want “shorter than the shortest possible lifetime.”