Hi Koichi,
> (This is just a side note about `local -' but unrelated to the main
> discussion): I didn't mention it because I thought `set -e' is merely
> an example to demonstrate the behavior of `defer', but if the handling
> of `set -e' is one of the main motivations for requesting `defer', I
Hi Koichi,
> I did notice your link to the Gist example, but I have to say that it
> misuses the RETURN trap. As I have written in the previous reply, the
> RETURN trap is already designed to be function-local so that it suits
> your use cases. However, the Gist version somehow disables the
> func
ot;foo;bar"
or whatever we end up using as a separator if it's not a semicolon.
That way as a user writing my script I never have to be aware of
what's already existing in a trap, I can always safely "add" my code,
without stomping over anybody else.
- Cynthia
On Fri, Oct 7, 2
, I do not think we should use it as a blocker as a
reason itself, personally.
Thanks,
Cynthia
On Sat, Oct 8, 2022 at 12:11 AM Koichi Murase wrote:
>
> 2022年10月8日(土) 12:04 Cynthia Coan :
> > [...]
> >
> > Otherwise, I think we can perhaps reword this into two smaller
>
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 i
e" 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 wrote:
>
> On Thu, Oct 6, 2022, at 4:08 PM, Cynthia Coan wrote:
> > I'd specific
Hey all,
I've started working on this idea, and before getting too far I'd like
to get general feedback on the feature before going too far. 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. Hopeful
