4 ms·

Defer is also hidden control flow. At the end of every block, you need to read backwards in the entire block to see if a defer was declared in order to determin

by kibwen 8mo ago

Defer is also hidden control flow. At the end of every block, you need to read backwards in the entire block to see if a defer was declared in order to determine where control will jump to. Please stop pretending that defer isn't hidden control flow. > RAII has also proven to be quite harmful in cases The downsides of defer are much worse than the "downsides" of RAII. Defer is manual and error-prone, something that you have to remember to do every single time.

sparkie 8mo ago
Defer is a restricted form of COMEFROM with automatic labels. You COMEFROM the end of the next `defer` block in the same scope, or from the end of the function (before `return`) if there is no more `defer`. The order of execution of defer-blocks is backwards (bottom-to-top) rather than the typical top-to-bottom. puts("foo"); defer { puts("bar"); } puts("baz"); defer { puts("qux"); } puts("corge"); return; Will evaluate: puts("foo"); puts("baz"); puts("corge"); puts("qux"); puts("bar"); return;
- vlowther 8mo ago
  That is the most cursed description I have seen on how defer works. Ever.
  - sparkie 8mo ago
    This is how it would look with explicit labels and comefrom: puts("foo"); before_defer0: comefrom after_defer1; puts("bar"); after_defer0: comefrom before_defer0; puts("baz"); before_defer1: comefrom before_ret; puts("qux"); after_defer1: comefrom before_defer1; puts("corge"); before_ret: comefrom after_defer0; return; --- `defer` is obviously not implemented in this way, it will re-order the code to flow top-to-bottom and have fewer branches, but the control flow is effectively the same thing. In theory a compiler could implement `comefrom` by re-ordering the basic blocks like `defer` does, so that the actual runtime evaluation of code is still top-to-bottom.

by kibwen 8mo ago

sparkie 8mo ago

Defer is a restricted form of COMEFROM with automatic labels. You COMEFROM the end of the next `defer` block in the same scope, or from the end of the function (before `return`) if there is no more `defer`. The order of execution of defer-blocks is backwards (bottom-to-top) rather than the typical top-to-bottom. puts("foo"); defer { puts("bar"); } puts("baz"); defer { puts("qux"); } puts("corge"); return; Will evaluate: puts("foo"); puts("baz"); puts("corge"); puts("qux"); puts("bar"); return;

vlowther 8mo ago
That is the most cursed description I have seen on how defer works. Ever.
- sparkie 8mo ago
  This is how it would look with explicit labels and comefrom: puts("foo"); before_defer0: comefrom after_defer1; puts("bar"); after_defer0: comefrom before_defer0; puts("baz"); before_defer1: comefrom before_ret; puts("qux"); after_defer1: comefrom before_defer1; puts("corge"); before_ret: comefrom after_defer0; return; --- `defer` is obviously not implemented in this way, it will re-order the code to flow top-to-bottom and have fewer branches, but the control flow is effectively the same thing. In theory a compiler could implement `comefrom` by re-ordering the basic blocks like `defer` does, so that the actual runtime evaluation of code is still top-to-bottom.