“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 <[email protected]> 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