Re: [Early Feedback] Pattern matching

After a coffee break, I think this is how the language could do this in a semantically pleasing way. interface iArrayA ['a' => string ] interface iArrayB extends iArrayA ['b' => string ] $arr is iArrayA &| iArrayB Best, Richard Miles > On Jun 26, 2024, at 11:57 AM, Richard Miles <richard@miles.systems> wrote: > > “Array-application will also be pushed to future-scope” > > > Dang, this is what I was looking forward to the most. Helping set some precedent on this issue, > and this is a solid start. I’ve been thinking about what it would look like for strictly typed > arrays in PHP for a while now. I think a custom implantation like SqlObjectStorage or SplFixedArray > could help performance since we now have a fixed list and no need for a hash table, and it may solve > some complexity in implementation. This is slightly off-topic, but if anyone is interested in > working on a typed arrays initiative, please contact me directly. > > > That said, I agree with Robert Landers, who wrote the following: > > There's no need to use ? to check for existence on a key, > so this: > > $arr is ['a' => string, ?'b' => string, ...]; > > should be this: > > $arr is ['a' => string, 'b' => ?string, …]; > > ______ > > Chuck Adams cleared that up with: > The first means b is an optional key, but if it’s there, can only be a string. The second > says b is a required key, but it may be a string or null. If there were a binding involved, that > determines the type of the binding in incompatible ways. > ______ > > I think there is a need to ensure a key does not exist even if we’re not happy about this > syntax, but if not having $arr is ['a' => string, 'b' => > ?string, …] would still make me very happy. > > Best, > > Richard Miles > > >> On Jun 24, 2024, at 5:31 PM, Larry Garfield <larry@garfieldtech.com> wrote: >> >> On Thu, Jun 20, 2024, at 5:38 PM, Larry Garfield wrote: >> >>> To that end, we're looking for *very high level* feedback on this RFC: >>> >>> https://wiki.php.net/rfc/pattern-matching >> >> Hi folks. Thank you to those who have offered feedback so far. Based on the discussion, >> here's what we're thinking of doing (still subject to change, of course): >> >> * We're going to move as to future-scope. >> There's enough weirdness around it that is independent of pattern matching itself that it will >> likely require its own discussion and RFC, and may or may not involve full pattern support. >> >> * Similarly, we're going to hold off on the weak-mode flag. It sounds like the >> language needs to do more to fix the definition of "weak mode" before it's really >> viable. :-( On the plus side, if the type system itself ever adds support for a "coercion >> permitted" flag, patterns should inherit that naturally, I think. >> >> * Array-application will also be pushed to future-scope. Again, there's enough >> type-system tie in here that is tangential to patterns that we'll pick that fight later. >> >> * Ilija and I have discussed regex patterns a bit further, and it sounds like they’re >> going to be rather complicated to implement. Even assuming we agree on the syntax for it, it would >> be a substantial amount of code to support. (It’s not like types or literals or range where we >> can just drop something pre-existing into a new function.) So we’re going to hold off on this one >> for now, though it does seem like a high-priority follow-up for the future. (Which doesn’t have >> to be us!) >> >> So let's not discuss the above items further at this point. >> >> * I'm going to do some additional research into other languages to see how they handle >> binding vs using variables from scope, and what syntax markers they use and where. Once we have a >> better sense of what is out there and is known to work, we can make a more informed plan for what we >> should do in PHP. (Whether using a variable from scope in the pattern is part of the initial RFC is >> still an open question, but we do need to design it alongside the capture part to ensure they >> don't conflict.) Stay tuned on this front. >> >> * We've removed the dedicated wildcard pattern, as it's equivalent to >> mixed. If there's interest, we're open to having a >> secondary vote to bring it back as a short-hand pattern. It's trivial to implement and we >> don't have strong feelings either way. >> >> * There's not been much discussion of range patterns. Anyone want to weigh in on >> those? >> >> * The placement of is on >> match() is still an open question. >> >> * No one has really weighed in on nested patterns for captured variables. Any thoughts >> there? >> >> * I’ve seen a suggestion for capturing the “rest” of an array when using … >> That’s an interesting idea, and we’ll explore it, though it looks like it may have some >> interesting implications that push it to future scope. It feels like a nice-to-have. >> >> Thanks all. >> >> --Larry Garfield >