“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
