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

[Cynthia Coan]

I think that's certainly a fair option, and a potential solution. The
reason for introducing a new "builtin" as opposed to utilizing a trap
is because safely appending to a trap can be filled with holes. Since
trap always overwrites what is in the trap, you have to be aware of
what is already in the trap, and ensure you are properly appending to
it (and that a previous error in the trap processing doesn't affect
you). This removes the nice benefit of multi-step setups, so for
example if we rewrite the scoped error mode with traps we get:

  ```
  scoped_error_mode() {
    if ! echo -n "$SHELLOPTS" | grep 'errexit' >/dev/null 2>&1; then
      echo "error mode off, enabling for this function"
      set -e
      trap "set +e" EXIT_LOCAL RETURN_LOCAL
    fi
    if ! echo -n "$SHELLOPTS" | grep 'pipefail' >/dev/null 2>&1; then
      echo "pipefail off, enabling for this function"
      set -o pipefail
      if [ "x$(trap -p EXIT_LOCAL)" != "x" ]; then
         trap "$(trap -p EXIT_LOCAL) ; set +o pipefail" # if dealing
with quotes have to sed them out
      fi
      if [ "x$(trap -p RETURN_LOCAL)" != "x" ]; then
         trap "$(trap -p RETURN_LOCAL); set +o pipefail"
      fi
   fi

    my_commands
    my_other_commands | piped-to
  }
  ```

This isn't terrible by any means, and is "more in line" with the
existing practices. I still think defer might be more simple, but that
is just my opinion! I think both are totally workable.

- Cynthia

On Thu, Oct 6, 2022 at 4:05 PM Lawrence Velázquez <vq@larryv.me> wrote:
>
> On Thu, Oct 6, 2022, at 4:08 PM, Cynthia Coan wrote:
> > I'd specifically like to propose a new built-in called `defer` which
> > acts like `eval` however is not parsed/expanded/run until it's scope
> > is leaving.  Hopefully "scope" is the correct word, I'm imagining it
> > running at the same time a local would go out of "scope" and be no
> > longer available (just before the locals are cleared, so locals can
> > still be used in expansion).
>
> I think it would be more natural to implement function-local RETURN
> and EXIT traps than introduce a second command that looks like
> 'trap' and quacks like 'trap' but is actually not 'trap'.  This
> could be done generically by adding the ability to "scope" traps
> to functions (possibly via a new option to 'trap' or a shopt à la
> zsh's LOCAL_TRAPS) or specifically by creating "local" variants of
> RETURN and EXIT.  Usage might look like this:
>
>     f() {
>         # new option
>         trap -f 'cleaning up' EXIT RETURN
>         cmd1
>         cmd2
>         cmd3
>     }
>
> or this:
>
>     g() {
>         # new traps
>         trap 'cleaning up' EXIT_LOCAL RETURN_LOCAL
>         cmdA
>         cmdB
>         cmdC
>     }
>
> --
> vq