Re: feature request: new builtin `defer`, scope delayed eval

[Cynthia Coan]

I definitely got the inspiration of the name from the Go programming
language. There are several other languages who use similar concepts
when dealing with cleanup where something like an RAII pattern to free
resources.

It sounds like we're leaning towards trap, over a new built-in which I
think is fair given its similarities. The question I think we have to
ask is "are we okay extending `trap` in these two ways" you mentioned,
or are we perhaps making `trap` into something it shouldn't be?
Another way to put it might be: are we using `trap`, or abusing it.
Are these changes to `trap` generally usable, are they breaking in any
way, or are they creating potential places for misuse that it wouldn't
be worth adding these features to an existing interface? I can't think
of any off the top of my head, but I'll give it some thought.

Otherwise, I think we can perhaps reword this into two smaller
features: "function local trap signals", and "options to safely
append/prepend to a trap" (for some definition of 'safe', perhaps this
just means separating by ';'? Unsure if there's a better way off the
top of my head).

- Cynthia

On Fri, Oct 7, 2022 at 7:49 PM Dale R. Worley <worley@alum.mit.edu> wrote:
>
> The Go programming language has a "defer" statement which is used
> considerably for exactly this purpose.  So we know that it's useful in
> practice.  The question remains what is a good way to introduce it into
> Bash.
>
> As others have noted, there is already a "trap" with similar
> functionality.  I'm not familiar with it, but it seems that it does not
> have "signal" choices that cover the the situation(s) we want "defer" to
> be triggered by.  However, that seems to be a straightforward extension.
>
> More important is "safely appending to a trap can be filled with holes".
> Why don't we allow a trap to be a sequence of strings, and define a new
> option to "trap" that prepends the argument string to the sequence?  (Go
> specifies that "defer" actions are executed in reverse order from the
> execution of the "defer" statements that establishd them.)
>
> This approach seems to have the functionality we want while being a
> small extension of an existing, similar mechanism.
>
> Dale