New Rules for Temporary lifetimes

compiler
1

I'm thinking about new rules for lifetimes of Temporary variables.

Last discussion by lang-team: Temporary lifetimes

I found that next new rules could be handy:

  1. First Rule - "extend" lifetime (to exclude "too short" temporary lifetimes). All Expressions and Statements must have boolean "property" isTmpConsumer, if it is true then temporary lifetime is extended through this Expression/Statement or no otherwise.

  2. Full list isTmpConsumer == false

  • ItemStatement
  • LetStatement
  • MacroStatement
  • ExprStatement if it is before another Statement

  1. The rest majority of Expressions are on the list where isTmpConsumer == true

  2. Second Rule - "cut" lifetime (to exclude "too long" temporary lifetimes). Each temporary variable must have boolean "property" isYoung, if it is true and isTmpConsumer == true then lifetime is extended through this Expression or it ends with this Expression if isYoung == false (or isTmpConsumer == false)

  3. Full list of Expressions, that convert temp variable property isYoung into false (isYoung = false) from another expression (most of them could produce new isYoung==true temporary variables):

  • IfCondExpr from itsef
  • WhileCondExpr from itsef
  • Operator1Expr from OperatorArgSingle
  • Operator2Expr (except AssignOperatorExpr) from OperatorArgLeft and OperatorArgRight
  • ArrayExpr from all ArrayElementExpr
  • ArrayIndexExpr from ArrayIndexCallierExpr and ArrayIndexIndexingExpr
  • TupleExpr from all TupleElementExpr
  • TupleIndexExpr from all TupleIndexCallierExpr
  • StructExpr from all StructFieldExpr and StructBaseExpr
  • CallExpr from all CallArgExpr and CallCallierExpr
  • MethodCallExpr from all MethodCallArgExpr and MethodCallCallierExpr
  • FieldExpr from FieldCallierExpr
  • RangeExpr from RangeFromExpr and RangeToExpr

Is it sound reasonable? Do I forget something?

2

You forgot to describe how these changes relate to the various problems identified in the link. Can you provide some practical examples of code that is currently rejected but will compile under the new rules (or vice versa)? Also, how does it compare in practice to the various proposals made in the link?

1 Like
3

Lang team and devs trying to find an "universal" way, when all temporary variable are erased. So, new lang-team proposal almost identical to mine First Rule.

The main difference is Second Rule. We distinguish "old temporary" and "young temporary" and only "old" ones are erased at the end of expression.

let x = { (&foo()).bar().baz().bam() };

I propose, that &foo lives till end of "bar()", new temporary "...bar()" lives till end of "baz()", new temporary "...baz()" lives till end of "bam()" and finally new temporary "...bam()" lives till end of "let".

The main difficulty is to mark which temporary variable was from witch expression was grabbed or re-grabbed, then mark them as "old", and destroy just "old" at the end of expressions.

4

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.