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

Re: RFC 0004 - defer {} syntax

Thread Previous | Thread Next
Tomasz Konojacki
June 20, 2021 06:53
Re: RFC 0004 - defer {} syntax
Message ID:
On Sat, 19 Jun 2021 22:41:24 -0400
"Ricardo Signes" <> wrote:

> 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."

I understand that this was purely hypothetical, but nevertheless, I
want to make it clear that deterministic destruction is a core language
feature, more core than much of the syntax, and we can't remove it
without breaking pretty much everything. It isn't just a quirk of the

RAII can't be implemented without deterministic destruction and
deterministic destruction can't be implemented without some kind of
object ownership mechanism. In Perl's case, it's reference counting.

Without RAII, there will be no automatic file closing, objects won't
have the ability clean-up after themselves. Languages based on pure
tracing garbage collection don't have those things. There's no cheat
code, it's impossible to implement. That's the reason why GC languages
have invented workarounds such as "try-with-resources" (Java), "using"
(C#) or, well, "defer".

To understand the problem with replacing deterministic destruction with
injectable defer blocks, let's imagine that open(), instead of returning
a refcounted filehandle with a destructor, injects a defer block to the
caller. The only reasonable thing that block could do is to close the
file at the end of the scope containing the open() call. That means it
would be impossible to pass the filehandle to the outer scope, e.g. by
"return". That's not good.

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About