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 <la...@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 >
