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 niedz., 25 paź 2026, 14:42 użytkownik Arsan Gamal <[email protected]> napisał: > Hello PHP Internals, > > I would like to propose an idea for discussion regarding the introduction > of effect declarations in PHP, with a particular focus on making function > behavior more explicit and improving the security and auditability of > sensitive operations. > > Currently, PHP function signatures describe parameters and return values > but do not indicate which external operations a function may perform. A > function may execute operating-system commands, access the filesystem, or > make network requests through its implementation or dependencies without > these operations being visible in its signature. > > I believe an effect system could help address this limitation by allowing > functions to declare the operations they may perform. These declarations > could support static analysis, contract checking, code auditing, and > potentially stronger security controls. > Proposed syntax > > As an initial proposal, effects could be declared alongside a function's > return type: > > function generateReport(string $input): string > effects [process.execute] > { > // Implementation > } > > Effects could also accept parameters to describe the scope of an operation: > > function generateReport(string $input): string > effects [ > process.execute( > commands: ['/usr/bin/report-renderer'] > ) > ] > { > // Implementation > } > > In this example, the effect declaration indicates that the function may > execute a process, with the declared contract restricting the intended > executable to the report renderer. > > The same concept could be extended to other operations: > > function readConfiguration(): string > effects [ > filesystem.read( > paths: ['/etc/myapp/config.json'] > ) > ] > { > // Implementation > } > > function fetchReport(string $url): string > effects [ > network.request( > hosts: ['api.example.com'] > ) > ] > { > // Implementation > } > > These examples are illustrative and are not intended to prescribe the > final grammar. The syntax, supported effect types, parameter formats, and > enforcement rules would need to be discussed and evaluated. > Effect checking and security > > I envision effects serving as explicit contracts describing the operations > a function may perform. A static analyzer or compiler could check whether > implementations and their dependencies respect these declarations, identify > undeclared effects, and make sensitive operations more visible during code > review. > > Parameterized effects could provide additional information about the > intended scope of an operation. For example, a function declaring a > process-execution effect restricted to a particular executable could be > checked for attempts to execute other programs. > > I would also like to explore how this proposal could complement a > capability-based security model. Effects and capabilities would have > separate responsibilities: effects would describe the operations and > constraints associated with a function, while capabilities would determine > which operations are authorized at runtime. > > For example, an application could grant a request handler permission to > execute a specific binary with defined argument constraints and resource > limits. The runtime would enforce that permission when a process is > created, independently of the function's effect declaration. > > This distinction is important because declaring an effect should not > automatically grant authority to perform the operation. Runtime enforcement > would remain necessary for security-sensitive operations, even if static > effect checking were available. > Scope and open questions > > I recognize that PHP's dynamic features, backward-compatibility > requirements, and native extension ecosystem present significant design and > implementation challenges. Some questions that would need further > exploration include: > > - > > Whether effects should be explicitly declared, inferred, or support > both approaches. > - > > How effects should propagate through function calls, closures, dynamic > calls, and third-party dependencies. > - > > How parameterized effects should be represented and validated. > - > > Whether effect contracts should be enforced by the PHP engine, > external static analysis tools, or a combination of both. > - > > How effects could integrate with runtime capabilities and existing > APIs. > - > > How strict enforcement could be introduced without breaking existing > PHP applications. > > The proposal would not, by itself, prevent vulnerabilities within the PHP > engine or native extensions. Any runtime security guarantees would depend > on the coverage and correctness of the enforcement mechanisms. > > I have started drafting an RFC exploring these ideas, using process > execution as an initial use case. I would welcome feedback on whether > effect declarations and parameterized effects would be a worthwhile > direction for PHP, whether the proposed syntax fits the language, and what > scope would be appropriate for an initial RFC. > > If there is interest, I would be happy to share the draft and work on a > proof of concept. > > Thank you for your time and consideration. > > Respectfully yours, > *Arsan Gamal* > Senior Software Engineer >
