develooper Front page | perl.perl5.porters | Postings from June 2021

Re: RFC 0004 - defer {} syntax

Thread Previous | Thread Next
From:
Dan Book
Date:
June 23, 2021 00:58
Subject:
Re: RFC 0004 - defer {} syntax
Message ID:
CABMkAVUPnOjRLwUK74YypEgqyU08wmabphbJLz9R+ydp726nrQ@mail.gmail.com
On Sun, Jun 20, 2021 at 8:23 AM Paul "LeoNerd" Evans <leonerd@leonerd.org.uk>
wrote:

> On Sat, 19 Jun 2021 22:41:24 -0400
> "Ricardo Signes" <perl.p5p@rjbs.manxome.org> wrote:
>
> > But when unitcheck was introduced, I remember thinking clearly and
> > repeatedly that I'd have used it far often if it had been possible to
> > inject the unitcheck upward one scope.  Honestly, I'd have to do a
> > fair bit more thinking about it to remember the use cases I had in
> > mind.  But you suggest (I think *very* hopefully) that we could
> > eventually get away from timely destruction if we had better defer
> > blocks.  I think often we'd like defer blocks to be produced by
> > reusable code, which does hint toward the idea of "defer this until
> > my calling scope is complete."
> >
> > Do you think this is an area in which we should consider nudging the
> > capabilities of this proposal?
>
> An exciting question. There's two parts to the answer:
>
> On the question of how to spell the syntax, I could imagine if we're
> going into the realm of core-provided namespaced functions and keywords
> (e.g. previous discussions on `string::trim` and `ref::type`) I could
> imagine an uplevel:: space for doing that kind of thing:
>
>   sub wibble {
>     uplevel::defer { say "This runs after Hello" }
>   }
>
>   {
>     wibble();
>     say "Hello";
>   }
>
> As to implementation, I have no idea how to create this. `defer {}`'s
> current implementation is just to use SAVEDESTRUCTOR_X() which pushes
> to the same savestack as things like variable scope clearing and
> `local` uses. That's strictly a stack, and you can't splice into it
> lower down. There have variously been times I have wanted such
> an ability, but equally other times (most notably while implementing
> async/await) when I have been thankful for its absence.
>
> I don't think I want to add this to the main body of the current
> proposal, but I can at least add a note in "future direction" to
> suggest that such an extension might become useful.
>

I concur with this, and will add that such a concept would also be
incredibly useful for the `local` operator, so maybe both utilities could
be enhanced the same way.

-Dan

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About