Hey Marco,
On 27.1.2026 13:45:06, Marco Pivetta wrote:
Hey Tim,
I went for "abstain".
I'm a proponent of functional programming paradigms, and I frequently
touch Haskell / Nix, which have `let ... in ...` and `... where ...` ,
which are nice.
I feel like cluttering the PHP language for something that is already
(in my own opinion) resolved by IIFEs (and inlining/optimization
thereof) is not necessary.
I don't mind if the feature makes it into the language, but I feel
like it just complicates the AST further, for very marginal gains.
Greets,
Marco Pivetta
That's pretty much the sentiment I share. It's additional complexity for
the language, with a benefit not worth it.
I definitely prefer this over context managers (though they don't solve
exactly the same goals, there's quite a bit of overlap).
But for me I'd like to see neither.
As to the more specific semantics of the RFC:
It's not natural to write code this way (especially if there are
multiple such objects created across a function - you don't want to nest
5 times, for 5 objects), and there are only very few instances where it
actually matters when exactly a value is destroyed.
While the examples certainly correctly show usages where it's useful, an
explicit unset(); just solves this as well in most cases. However a
let() is much more implicit than the actual unset() telling me "I NEED
this to be cleared here". It also doesn't prevent me from outliving the
value.
It feels like let is supposed to be clearing the object. However, with
your example for process_file() it's fine. However if you have
zend.exception_ignore_args=0 (as you should if you disable displaying
errors) and forward the $file object as an arg (e.g. read_all($file)),
the $file object will be attached to the exception (being an arg). It
will not, as one may expect, be actually freed when the exception is thrown.
That's subtle, and let() isn't the holy grail for solving these things.
It creates false expectations in sufficiently complex code.
The main remaining utility I see in let() is highlighting intentions,
rather than being actually useful in the language. Which goes back to
the first point of "additional complexity, but not worth it".
Thanks,
Bob
