Re: Proposal for Discussion: Effect Declarations and Capability-Gated Process Execution in PHP

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