Hey Michał, This raises a broader architectural question:
> Should Level 3 typed arrays rely on function-specific guards for these > APIs, or should internal APIs gradually move towards a model where the > result is built in a temporary zval and only assigned through a single > typed assignment after construction? > That approach would naturally preserve atomicity and would work not only > for list, but also for future typed arrays. > I'm not claiming this makes Level 3 impossible. Quite the opposite - I > think it highlights an implementation issue that any persistent refinement > over mutable arrays will eventually have to solve, regardless of whether > the refinement is list, array<T>, or something else. > I'd be interested to hear whether this has already been considered during > the design of Level 3, or whether this class of internal APIs simply hasn't > been explored yet. This is very interesting. I thought about it, but didn't dive too much into it. However, from some checks I've done myself, when you say: "or should internal APIs gradually move towards a model where the result is built in a temporary zval and only assigned through a single typed assignment after construction?" That going into this direction would be very beneficial, however, I think this would imply touching a lot of things that can have a broader impact. If this is something that people would agree to follow, I think it would be great. I've been implementing a prototype of persistent list-typed properties > (where list is a structural refinement of array, i.e. array_is_list() must > always hold), BTW, on this, is this already an RFC, or is the implementation somewhere I can take a look at? As it was advised before, since this RFC can be affected by the generics design, for now I'll keep the RFC on hold, as well as because it's not a PHP 8.6 one, and as Larry asked, since we're close to PHP 8.6, this version should be the focus. But I'd be happy to discuss and improve the RFC along the way. *---* *Best Regards,* *Wendell Adriel.* *Software Engineer & Architect* *https://wendelladriel.com <https://wendelladriel.com>*
