On Tue, Oct 27, 2026, at 4:38 AM, Damian Jóźwiak wrote:
> Hi Arsan,
>
> I find the idea interesting, but I have two questions:
>
> 1. Why introduce new syntax instead of using PHP attributes? Isn't this
> exactly the kind of metadata that attributes were designed for? What
> would be the advantage of introducing a new language construct?
>
> 2. Are you aware of any existing implementations of a similar effect
> system in other programming languages? I'd be interested to see how
> other languages approach this problem and whether there are any
> established patterns PHP could build upon.
>
> Best regards,
> Damian
0. Please do not top post.
1. Attributes would be useful for static-analysis level enforcement. Something
like:
#[AllowedEffects(AllowedEffects::Output)]
function doesAThing(string $thing) {
print $thing;
}
And then an SA tool could object if a print statement appears in a method
without that attribute on it. That could be implemented today by any of the SA
tools in the ecosystem (though they seem to prefer docblock comments to
attributes, unfortunately).
If we wanted something that is enforced by the language, however, then it would
need either a language-enforced attribute or new native syntax. And the
general zeitgeist is that Internals favors new syntax over attributes for
things that have a guaranteed-impact rather than just an optional add-on.
2. "Effect systems" are a very specific thing in comp sci research. I'm not
sure that what is proposed here counts as such. (Think exceptions that return
to their point of throw after the handler completes. It seems mainly useful as
a way to keep a routine technically-pure while still letting it do useful
things.) There are some academic Haskell-like languages with it, but I don't
know of anything in widespread use.
What is described here feels more like gated capabilities, similar to what Wasm
does. It is an interesting concept, but for it to work it would need to
integrate at a very low level. The engine would need to explicitly fail a
function that tries calling print without the "I do output" flag, or opening a
process without the "I start processes" flag, or reading from the file system
without the "I read files" flag. The biggest issue there is, unsurprisingly,
backward compatibility. A new PHP release that fails on any function that has
a print or fopen statement in it until you add new syntax not available in
earlier versions is a complete non-starter.
As noted, it would also need some way to specify a resource dynamically; the
file path accessed will be defined at runtime, for instance. In the case of
Wasm, the runtime itself passes the path to use INTO the application,
chroot-style. (At least I think that's how it works; I'm going off of memory
of reading the docs a while back.) I don't see how PHP could get there without
completely unacceptable BC breaks.
So I like the idea in the abstract, but the first and most important question
is how to make something like this piecemeal opt-in and still meaningful.
Because if we can't do that, then we can't do it period.
--Larry Garfield
