Re: [RFC] Typed array declarations

pon., 20 lip 2026 o 13:48 Wendell Adriel <wendelladriel.ti@gmail.com> napisał(a): > 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? > I actually moved away from the direction I originally suggested (adding element constraints to arrays). I'm now exploring a separate approach based on dedicated immutable value types, but it's still too early to discuss as a concrete proposal. I'd rather wait until the design has stabilized. Cheers, Michał Marcin Brzuchalski