[RFC][Discussion] use construct (Block Scoping)

Hi

Am 2025-11-04 03:08, schrieb Ben Ramsey:

In general, I support this RFC. I’d like to see examples from other
programming languages, though. You mention C# and Hack above. Can you
elaborate in the RFC on how they implement this functionality? What
about other programming languages? I know some (Rust maybe?) are scoped
to blocks by default.

Please have a look at Seifeddine's previous reply to Edmond
(https://news-web.php.net/php.internals/129076) and my reply to Arnaud
that I just sent (https://news-web.php.net/php.internals/129087).

There are two things to consider when comparing against other
programming languages. PHP's semantics do not exactly fit any of these,
which means that transferring some concept from another programming
language directly does not work.

1. Scoping:

Many programming languages with explicit variable declarations are block
scoped. This includes Rust (which you correctly mentioned), but also C,
C++, Java, JavaScript (with let and const). Some of them allow shadowing
variables from the scope and some don't.

2. Handling of Lifetimes:

As I mentioned in my reply to Arnaud, PHP is pretty unique in the list
of programming languages with automated memory management in that it
does not primarily use an “unpredictable” garbage collector for memory
management, but instead uses reference counting with reliable destructor
semantics (that are documented). This is different from e.g. Java where
the so-called “finalizers” run at an unpredictable point in time when
the GC feels like cleaning up an object. PHP's semantics are close to
those of C++ (where this kind of memory management is called RAII) or
Rust.

For this reason, PHP just needs some generic “syntactic sugar” for
unset() that is compatible with all existing functionality using
__destruct() for those RAII semantics.

Best regards
Tim Düsterhus

Hi

Am 2025-11-04 06:16, schrieb Nick:

I think the three existing meanings of use are enough. A new keyword
would be better.
But, if a new keyword, why not scoped?

Thank for the keyword suggestion. Personally I could also imagine
let(), possibly combined with an in:

 let ($x = 10, $y) in {
     var_dump($x); // int(10)
     var_dump($y); // `NULL` 
     $z = 20;
 }

Best regards
Tim Düsterhus

Hi

Am 2025-11-04 07:08, schrieb Bruce Weirdan:

What would happen to the variables introduced in the statements
block, rather than in use()? Will they still be available outside of
the
block?

Yes. The construct only affects the variables listed in the “declaration
list”. I have adjusted the “simple example” to introduce a new variable
$z that is initially defined in the block, but not listed in the
declaration list to make that clearer.

use () {
  $number = 42;
}
var_dump($number); // what happens here?

Also, is an empty list of vars in use (as in the example above)
allowed?

That is a syntax error (unexpected )).

Best regards
Tim Düsterhus

Hello all!

Thank you for the RFC, it has been missing for many years.
If I understand correctly, are you proposing to call unset at the
end of the block?

I see that the Future Scope section mentions Disposable.
But if your goal is to introduce behavior based on Disposable,
wouldn’t that conflict with the logic of the current RFC?
I see a clear pitfall here.

If you accept this RFC with the unset operation, you will later need
a new keyword for Disposal, because these are two entirely different
scenarios.
(Should I explain why?)

In this context, I also see a problem, as if the RFC is trying to
introduce two different features into the language:

1. Scope – a visibility area. It is the scope that has the unset logic.
2. Using – a guaranteed call of a disposal function.

Because of this, logical issues are likely to arise. If the RFC’s goal
is unclear and it tries to cover both tasks, the solution risks losing
its clarity.

P.S.
Regarding the questions in the Open Issues, option A seems to have
more explicit behavior than option B.

---

Best Regards, Ed

Hello,

Thank you for the feedback.

Regarding the Disposable interface: introducing it in the future
won't require new syntax. The use construct can work with both
__destruct (current behavior) and a future disposal interface.

The idea is to introduce an interface like:

interface Disposable {
  public function dispose(?Throwable $throwable = null): void;
}

With use:

use ($foo = new Something()) {
  // work
} // ->dispose(null) called on success, ->dispose($exception) on failure

This mimics Python's context manager protocol. The dispose() method
would be called before __destruct, allowing objects to distinguish
between successful completion and failure.

However, there's nothing stopping us from shipping without it. The
lock example in the RFC doesn't need this, locks are freed
automatically in __destruct. The initial version relying solely on
__destruct works fine for most use cases.

On the name "Disposable": I'm not really a fan of this name
myself. It was just my initial thinking when trying to copy Hack. We
can come up with something better later.

On Hack's approach: Hack has a Disposable interface, but it
works differently: disposable objects must maintain refcount=1, can't
be assigned to properties, and functions returning disposables need
<<__ReturnDisposable>>. This is enforced statically by their
analyzer. At runtime, they're just regular PHP objects. We can't
replicate this in PHP.

The refcount problem: A disposal interface has its issues. Once
dispose() is called, there may still be references to the object
somewhere, leaving it in an undesirable state, unless we add a way to
enforce refcount = 1.

A disposal interface without exception awareness brings limited value.
But with ?Throwable, it becomes useful:

use ($transaction = $ctx->beginTransaction()) {
  // work
} // Transaction::dispose(?Throwable) called, then __destruct

Without dispose(?Throwable), the transaction can't know whether to
commit or rollback, __destruct alone can't distinguish success from
failure.

The key point: the initial version (relying on __destruct) and a
future disposal interface don't conflict.

Thanks,
Seifeddine Gmati.

Hi

Am 2025-11-04 13:31, schrieb Arnaud Le Blanc:

The proposal relies on destructors or automatic closing of resources,
but
this should not be relied on when timing matters. In general,
destructors
should be avoided IMHO [4][5]. They are useful in languages with
stack-allocated variables because timing and order can be guaranteed,
but
not in heap-allocated languages with automatic GC. PHP
resources/objects
are heap-allocated, and its GC mechanism behavior/semantics is similar
to
Java's due to cycles: resource/objects are not guaranteed to be
closed/disposed of immediately, and the order in which this happens is
undefined.

This is misrepresenting how PHP’s semantics around lifetimes work and
using that as a strawman argument to build something that does not fit
the existing semantics of PHP / the direction PHP is taking as of late.

PHP’s main mechanism of managing lifetimes is reference counting and by
that its semantics are much closer to those of languages that you call
“stack allocated”. Specifically PHP's semantics around resources and
objects match the semantics of std::shared_ptr() (C++) or Rc (Rust),
which - like PHP - are languages that guarantee that destructors are
predictably executed. Namely exactly when the reference count falls to
zero.

This is also documented and thus an explicit part of the semantics that
PHP users rely on - and not just an implementation detail:
https://www.php.net/manual/en/language.oop5.decon.php#language.oop5.decon.destructor.
The file locking example using Seifeddine's PSL library from the RFC is
a real-world use case that successfully relies on these semantics.

It is true that the point in time when the reference count falls to zero
is unpredictable in case of cycles, since this is dependent on the
assistance of the cycle collector. Cycles however are a comparatively
rare situation, particularly when dealing with a resource object. These
situations are also easy to resolve using the same mechanism that one
would use in C++ to deal with shared_ptr cycles, e.g. by including a
WeakReference for one of the directions.

Here are some use-cases that Python's with, C#'s using, or Java's
try-with were designed to address, but are not addressed by this RFC:

// Commit the transaction as soon as the block is left, or roll it back
if
an exception is thrown:
with ($db->beginTransaction() as $transaction) {
$transaction->execute(...);
$transaction->execute(...);
}

If $transaction escapes, it's not committed at the end of the block.
Regardless, it's not possible to automatically rollback the transaction
in
case of exception.

This is easily solved by making the “commit” operation explicit and not
relying on exceptions for control flow. The suggested implicit commit is
dangerous, since it might accidentally commit the transaction when
undesired (e.g. when adding a guard clause with an early return). Here's
an example:

 <?php

 final class Transaction {
     private bool $finalized = false;

     public function __construct() {
         echo "BEGIN", PHP_EOL;
     }

     public function commit() {
         $this->finalized = true;
         echo "COMMIT", PHP_EOL;
     }

     public function __destruct() {
         if (!$this->finalized) {
             echo "ROLLBACK", PHP_EOL;
         }
     }
 }

 use ($t = new Transaction()) {
     $t->commit();
 }

Nevertheless, this RFC acknowledges that use case as part of the “Future
Scope” section, as Seifeddine also mentioned in a previous reply to
Edmond: https://news-web.php.net/php.internals/129076

// Close file descriptor as soon as the block is left:
with (get_fd() as $fd) {
// ...
}

If $fd escapes, it's not closed at the end of the block. This may
affect
the program's behavior is various ways:

• The system's file descriptor limit may be reached before the GC
  triggers
• If $fd was a socket, and the other side waits for closing, it may
  hang
• If $fd has unflushed writes, readers will have an inconsistent view

If $fd escapes and is nevertheless closed at the end of the block, this
may affect the program's behavior in various ways:

• Suddenly any operation on the file descriptor fails.

PHP has gradually been moving towards “making illegal states
unrepresentable”. With the migration from resources to objects and the
removal of the associated _close() functions, PHP developers and
static analysis tools can rely on the fact that having a reference to
the object means that the reference will always be valid. This is also
something that Kamil mentioned as a good thing in the RFC discussion for
the PDO::disconnect() method:
https://news-web.php.net/php.internals/128742

I'd like to note again that “The system's file descriptor limit may be
reached before the GC triggers” is misrepresenting how lifetimes work in
PHP. Unless the file descriptor somehow ends up as a part of a cycle, it
will reliably be closed exactly when nothing holds a reference to it -
i.e. when nothing is interesting in making use of the FD any longer.

Being able to let resource objects escape is a feature, since this
allows to reliably pass locks around without the resource suddenly
getting unlocked.

Escaping/capturing is difficult to avoid, especially in large code
bases,
as it can not be checked with static analysis, typing, or avoided by
means
of API design. Sometimes it's even necessary, e.g. a file descriptor
may be
referenced by an I/O polling mechanism.

This is true, but equally affects “not closing” and “forcibly closing”
the resource. In case of forcibly closing, your I/O polling mechanism
might suddenly see a dead file descriptor (or worse: a reassigned one) -
and static analysis tools need to report every single method call as
“might possibly throw an Exception”.

Introducing a Disposable interface (similar to C#'s IDisposable) to
allow
objects to define custom, explicit cleanup logic that is automatically
called by use.

I'm in favor of introducing this immediately, for the reasons above,
and
[…]

I refer to Seifeddine's reply to Edmond:
https://news-web.php.net/php.internals/129076

Best regards
Tim Düsterhus

Hello internals,

Tim and I would like to open the discussion on our new RFC that we've been working on: "use construct (Block Scoping)".

We wanted to raise a few initial points:

• The RFC proposes the use keyword. What are your thoughts on a new using keyword instead, similar to C# or Hack?

• How do you feel about the questions raised in the "Open Issues" section?

• What are your general thoughts on the RFC?

Please find the following resources for your reference:

• RFC: https://wiki.php.net/rfc/optin_block_scoping

• POC: https://github.com/php/php-src/compare/master...TimWolla:php-src:block-scope

Thanks,

Seifeddine Gmati.

Hello,

One thing that isn't clear with this RFC is what happens to things redefined in the scope?

$a = 10;

use ($a = 5) {
var_dump($a);
}

var_dump($a); // unset or 10?

— Rob

lol, I just saw "open issues" ... so, never mind. I like option B.

— Rob

Hi

Am 2025-11-04 16:50, schrieb Tim Düsterhus:

Given the immediate and clear unanimous responses preferring option B
(restoring the original values), this is something we'll go with. I'll
look into updating the implementation later this week and we'll then
update the RFC based on the insights coming out of the implementation
(e.g. the exact semantics and possible edge cases).

I just updated the implementation in the branch already. The RFC text
will follow.

Best regards
Tim Düsterhus

Hi

Apologies for the late response. An unexpected high priority task came
up at work on Thursday and I wanted to make sure to provide a proper reply.

I agree with Ed and with Arnaud: this feels like it's trying to squeeze two different features into one syntax and ends up with an awkward version of both.

We don't think so. Our goal with this proposal is - as the title of the
RFC suggests - making block scoping / limiting lifetimes of variables
more convenient to use. The goal is to make it easier for developers and
static analysis tools to reason about the code, for example because
variables are less likely to implicitly change their type.

For this reason the RFC very intentionally relies on the existing
semantics of PHP and leaves anything more complicated to future scope,
as Seifeddine also mentioned in response to Edmond.

For block scoping of "normal" variables it feels clunky to add an extra block, rather than declaring the variable with a keyword like "let" or "var". This is particularly obvious in the foreach example, where the variable has to be named twice on one line:

use ($value) foreach ($array as &$value) {

Languages with a keyword for declaring variable scope instead let you write the equivalent of this:

foreach ($array as let &$value) {

Requiring to declare all block scoped variables at the start of the
block is an intentional decision to keep the scope easy to reason about.

Consider this example:

  function foo() {
      $a = 1;
      var_dump($a);
      {
          var_dump($a);
          let $a = 2;
          var_dump($a);
      }
      var_dump($a);
  }

What would you expect the output of each of the var_dump()s to be?

With regard to the foreach, I agree there is no ambiguity. I can imagine
a follow-up that desugars:

  foreach ($array as let &$value);

to

  use ($value) foreach ($array as &$value);

Or if you feel that this is important to have right away, I can look
into how complicated the implementation would be?

I think splitting the two use cases (context managers and scoped variables) would allow us to have much better solutions for both.

As mentioned above, this RFC explicitly is not a context manager
proposal. It's scoping - but it would make the existing lifetime
semantics easier accessible for what you call context managers.

Given the opinions disliking overloading the use() keyword, I have
discussed the keyword choice with Seifeddine. Personally I prefer
let() over all alternatives for this reason.

Best regards
Tim Düsterhus