Re: [RFC] Scope functions

From: Date: Mon, 01 Jun 2026 22:44:16 +0000
Subject: Re: [RFC] Scope functions
References: 1  Groups: php.internals 
Request: Send a blank email to internals+get-131092@lists.php.net to get a copy of this message
On Tuesday 19 May 2026 11:45:14 (+02:00), Ondřej Mirtes wrote: > On 6. 5. 2026 at 22:09:45, Bob Weinand <bobwei9@hotmail.com> wrote: > > > Volker and I drafted a RFC: > > > > Hello, I’d like to offer my 2c as PHPStan maintainer. References are really > hard to wrap our head around. [...] I only just saw this discussion – the combinatorial explosion Ondřej describes with references and closures is something I’ve been brushing against while working on the *scanf() counter fix for PHPStan. One thought that’s been growing out of that work and the original %c report php-src GH-19088: what if PHP could declare the return arity of a function directly? Something like: .listing function fn(): [int, Error|null] { … } // binary return function fn(): [] { … } // nulary return function fn(): [int...] { … } // variadic int return (zero or more) function fn(): [int, ...] { … } // variadic int return (one or more) The dot-dot-dot '...' borrows the left‑hand type if none is given (or means mixed if no left type). A call would destructure naturally: .listing [$a, $b, $c] = fn(); // or with null‑filling: [$a, $b, $c] = fn() + [null, null, null]; This would give the static analyser a fixed skeleton to hang its inferences on, even when the actual return is variadic. The combinatorial explosion of tracking references through closures would still exist, but the return site itself would be a clear contract. The analyser wouldn’t need to guess the shape of the returned array; it would be declared right there, much like the counter in PHPStan asks the runtime for the exact count of placeholders. This isn’t an RFC – I’m not fond of writing those. It’s just a paper‑trail: a small idea that emerged from fixing a decades‑old sscanf bug, and that might be useful to someone thinking about return types in the future. The counter already measures return arity today; a native syntax would just make that measurement explicit. I find this ordinarily simplistic and therefore wonder if there isn't prior art, specifically in PHP for this. Feel free to send me any references off‑list or ping me in room 11. -- hakre

« previous php.internals (#131092) next »