On Fri, May 15, 2026, at 6:10 AM, Rowan Tommins [IMSoP] wrote: > On 15 May 2026 00:32:05 BST, Seifeddine Gmati <[email protected]> > wrote: > >>Generic type information currently lives in optional levels because it >>lives in optional syntax (docblocks). > > > This is, quite frankly, nonsense. > > If you write a function with no native type information, but an > "@return int" docblock, PHPStan will report an error for a missing > return statement at Level 0, and for an incorrect return statement on > Level 3. > > There's no relationship between the syntax needed and the types of > analysis performed. > > >> That's the point: native syntax means the language >>did the work, and tools surface violations at whatever strictness the >>user already has configured. > > > As Daniil pointed out, SA tools analyse code with offline parsers, not > by loading and reflecting it; so the native enforcement of arity etc > will still need to be reimplemented in each tool. > > The RFC will act as a standardisation of what tools *should* enforce > around those things; but that could equally be done by agreeing a set > of conformance tests based on the existing docblock syntax. In fact, > those conformance tests would be needed whatever the syntax, if the > goal is to eliminate different handling in different tools. > > >>The actual situation is that PHP has a runtime-checked layer (what the >>engine validates) and an SA-checked layer (what tools verify). The two >>layers complement each other. Native generics formalize a part of the >>SA-checked layer that the engine can partially absorb. > > > I can agree with this framing. I think where we differ is that you see > unifying those layers in one syntax as a good thing, but I see it as a > bad thing: I think it is useful to be able to look at the code, and > understand which parts are definitely going to be enforced by the > runtime-checked layer. > > I think the ideal is to somehow create a standardised syntax for the > SA-checked layer, but still keep it separate from the syntax for the > runtime-checked layer. If neither docblocks nor attributes are a good > basis for that, maybe there's some other primitive we can add so that > users can mark both the "runtime type" and the "SA type". > > Straw man example: > > class Foo ~~Foo<T> extends Bar ~~Bar<int,T> { > public function foo(string ~~non-empty-string $in): array ~~list<T> { > ... > > > Maybe PHP would process the syntax, but not the semantics, of the extra > type information; SA tools would then be free to invent new pseudotypes > within that framework, without needing to wait for a full PHP release > cycle every time.
This feels like it would be isomorphic to attributes, no? Syntax validated, available via reflection, but nothing done with it. For me, my big concern is issues like what Anna Filina raised on Mastodon: https://phpc.social/deck/@afilina/116575372360401330 Every time we tighten up a permissive/unenforced rule to make it enforced, we alienate someone who was (wrongly? but innocently) taking advantage of that unenforcement. For the most part I have still supported those efforts, but we have to be mindful and careful with them. Adding another permissive/unenforced rule makes me nervous. (And as has been stated repeatedly, no, "everyone who matters uses SA" is not an answer.) I'm OK with this RFC not solving every type system concern ever. non-empty-string et al, I'm fine leaving for another time, as there's a number of ways to go about them. It's the "do this but we won't enforce it, yet, maybe we will later" landmine that concerns me. What would be convincing to me is 1. Actual data on SA usage vs generics. 2. Some proofs of concept that the problem is smaller than I am making it out to be, eg, "here's why almost no one will be dumb enough to put the wrong typed variable on the same line as the conflicting type declaration." 3. Some data on PHPStorm's market share, since in practice that would count as an SA tool (and would presumably give you a red squiggle every time you got it wrong). Or something along those lines. As I noted in my recent blog post, the million dollar question is "what is our threshold for how many people we're OK shooting themselves in the foot with this gap, and is the predicted number that actually will below that threshold?" That's the issue that needs to be addressed, IMO. --Larry Garfield
