Hey, I spent some time reading through the docs and also looking at the implementation and benchmarks. Overall this is really solid work – it’s clear a lot of thought went into both the design and the performance side.
The trust boundary argument is absolutely the strongest point here. Static analysis tools like PHPStan or Psalm are great, but they fundamentally can’t validate data coming from DBs, APIs, JSON decoding, etc. That gap is very real, and runtime validation at those boundaries is where this actually shines.
I also like the approach of keeping everything opt-in via type declarations. It feels very natural in PHP terms, similar to how strict_types works, and it avoids surprising existing code with unexpected overhead.
On performance: the optimizations you describe are genuinely impressive. Escape analysis for literals and the caching around validated shapes make the overhead much more reasonable than I expected. For most real-world boundary cases, 1–20% overhead seems like a fair trade-off for the guarantees you get.
Shape aliases are another really nice touch. Without them, repeating array{id: int, name: string, ...} everywhere would get old very quickly. This makes the feature actually usable in larger codebases.
One thing that does worry me a bit is the object array case. The ~229% overhead there is pretty scary if you imagine something like array coming out of Doctrine or Eloquent. I’m wondering if there’s room for further optimization there, maybe caching per class entry or skipping validation for objects that already carry strong type information. Might be worth profiling that path more deeply.
I also get why validation only happens on return/assignment, but it’s worth being very explicit about the limitations. Once the array is validated, it can still be mutated into an invalid state later, and that might surprise people at first. This feels like a documentation challenge more than a design flaw, and maybe something like readonly shapes could be explored in a future RFC.
Related to that, open shapes by default make me a little nervous. Allowing extra keys is pragmatic, but it can also hide bugs or accidentally leak data. Even if closed shapes aren’t part of this RFC, it might be good to clearly call this out and maybe sketch a possible syntax for exact shapes down the line.
On the social side: the technical work looks strong, but getting internals to vote yes is always the hard part. This is a big feature, and history hasn’t been kind to large RFCs (generics being the obvious example). I wonder if there’s a path where this gets split up or proven incrementally, or backed by real-world experiments in frameworks to show concrete value.
Personally, I would absolutely use this at API, DB, and framework boundaries. The combination of runtime validation and reflection support is something PHP doesn’t really have today.
Curious if you’ve already profiled where most of the object-array overhead comes from, and whether you’ve had any early feedback from internals folks yet.
Anyway, really interesting work. I hope this makes it further in the process.
Hey, I spent some time reading through the docs and also looking at the implementation and benchmarks. Overall this is really solid work – it’s clear a lot of thought went into both the design and the performance side.
The trust boundary argument is absolutely the strongest point here. Static analysis tools like PHPStan or Psalm are great, but they fundamentally can’t validate data coming from DBs, APIs, JSON decoding, etc. That gap is very real, and runtime validation at those boundaries is where this actually shines.
I also like the approach of keeping everything opt-in via type declarations. It feels very natural in PHP terms, similar to how strict_types works, and it avoids surprising existing code with unexpected overhead.
On performance: the optimizations you describe are genuinely impressive. Escape analysis for literals and the caching around validated shapes make the overhead much more reasonable than I expected. For most real-world boundary cases, 1–20% overhead seems like a fair trade-off for the guarantees you get.
Shape aliases are another really nice touch. Without them, repeating array{id: int, name: string, ...} everywhere would get old very quickly. This makes the feature actually usable in larger codebases.
One thing that does worry me a bit is the object array case. The ~229% overhead there is pretty scary if you imagine something like array coming out of Doctrine or Eloquent. I’m wondering if there’s room for further optimization there, maybe caching per class entry or skipping validation for objects that already carry strong type information. Might be worth profiling that path more deeply.
I also get why validation only happens on return/assignment, but it’s worth being very explicit about the limitations. Once the array is validated, it can still be mutated into an invalid state later, and that might surprise people at first. This feels like a documentation challenge more than a design flaw, and maybe something like readonly shapes could be explored in a future RFC.
Related to that, open shapes by default make me a little nervous. Allowing extra keys is pragmatic, but it can also hide bugs or accidentally leak data. Even if closed shapes aren’t part of this RFC, it might be good to clearly call this out and maybe sketch a possible syntax for exact shapes down the line.
On the social side: the technical work looks strong, but getting internals to vote yes is always the hard part. This is a big feature, and history hasn’t been kind to large RFCs (generics being the obvious example). I wonder if there’s a path where this gets split up or proven incrementally, or backed by real-world experiments in frameworks to show concrete value.
Personally, I would absolutely use this at API, DB, and framework boundaries. The combination of runtime validation and reflection support is something PHP doesn’t really have today.
Curious if you’ve already profiled where most of the object-array overhead comes from, and whether you’ve had any early feedback from internals folks yet.
Anyway, really interesting work. I hope this makes it further in the process.