[Early Feedback] Pattern matching

You won't believe it, but just right now I've been thinking about that it
would be a wonderful feature for PHP to have some kind of type-tests (like
$a is Foo&Bar or $b is Foo|Baz|null), and here you write out this email.

I didn't read the whole RFC, but I'd like to say that having at least
aforementioned type tests would be really helpful

Thank you for your effort and have a nice day!

On Thu, Jun 20, 2024 at 7:41 PM Larry Garfield larry@garfieldtech.com
wrote:

Hello, peoples.

Ilija and I have been working on and off on an RFC for pattern matching
since the early work on Enumerations. A number of people have noticed and
said they're looking forward to it.

It's definitely not going to make it into 8.4, but we are looking for
early feedback on scoping the RFC. In short, there's a whole bunch of
possible patterns that could be implemented, and some of them we already
have, but we want to get a sense of what scope the zeitgeist would want in
the "initial" RFC, which would be appropriate as secondary votes, and which
we should explicitly save-for-later. The goal is to not spend time on
particular patterns that will be contentious or not pass, and focus effort
on fleshing out and polishing those that do have a decent consensus. (And
thereby, we hope, avoiding an RFC failing because enough people dislike one
little part of it.)

To that end, we're looking for very high level feedback on this RFC:

https://wiki.php.net/rfc/pattern-matching

By "very high level," I mean, please, do not sweat specific syntax details
right now. That's a distraction. What we're asking right now is "which of
these patterns should we spend time sweating specific syntax details on in
the coming weeks/months?" There will be ample time for detail bikeshedding
later, and we've identified a couple of areas where we know for certain
further syntax development will be needed because we both hate the current
syntax. :-)

If you want to just read the Overview section for a survey of the possible
patterns and our current recommendations, you likely don't need to read the
rest of the RFC at this point. You can if you want, but again, please stay
high-level. Our goal at the moment is to get enough feedback to organize
the different options into three groups:

1. Part of the RFC.
2. Secondary votes in the RFC.
3. Future Scope.

So we know where to focus our efforts to bring it to a proper discussion.

Thank you all for your participation.

--
Larry Garfield
larry@garfieldtech.com

I have been looking forward to this RFC, it's such a quality of life to be
able to do all this! In terms of things to focus on, I'd personally be very
happy with the property/param guards, "as" and "is <regex>", but I won't
say no to anything we can get extra here because it's all really nice to
have.

I noticed that with array structure patterns the count is omitted when
using ...

if ($list is [1, 3, ...]) {
  print "Yes";
}
// True.  Equivalent to:
if (is_array($list)
    && array_key_exists(0, $list) && $list[0] === 1
    && array_key_exists(1, $list) && $list[1] === 3
    ) {
    print "Yes";
}

Wouldn't this need a count($list) >= 2? I'm not sure if the
underlying mechanism does the count check as well, but it seems to me like
a guard clause for performance reasons in the PHP variant. Maybe a tangent,
what about iterators?

"Limited expression pattern"
I think this would be very valuable to have, though in the proposal it
seems cumbersome to use regardless of syntax. It feels like I'm going to be
using the variable binding less often than matching against other
variables, what about an "out" equivalent?

$result = match ($p) is {
  Point{x: 3, y: 9, $z} => "x is 3, y is 9, z is $z",
  Point{$x, $y, $z} => "x is $x, y is $y, z is $z",
};
// vs
$x = 3;
$y = 9;
$result = match ($p) is {
  Point{x: 3, y: 9, out $z} => "x is 3, y is 9, z is $z",
  Point{$x, $y, out $z} => "x is 3, y is 9, z is $z",
};

To me this makes it much more readable, just not sure if this is even
feasible. This is not meant as bikeshedding the syntax, more of an
alternative approach to when to use which.

Larry Garfield larry@garfieldtech.com hat am 20.06.2024 19:38 CEST geschrieben:

Hello, peoples.

Ilija and I have been working on and off on an RFC for pattern matching since the early work on Enumerations. A number of people have noticed and said they're looking forward to it.

It's definitely not going to make it into 8.4, but we are looking for early feedback on scoping the RFC. In short, there's a whole bunch of possible patterns that could be implemented, and some of them we already have, but we want to get a sense of what scope the zeitgeist would want in the "initial" RFC, which would be appropriate as secondary votes, and which we should explicitly save-for-later. The goal is to not spend time on particular patterns that will be contentious or not pass, and focus effort on fleshing out and polishing those that do have a decent consensus. (And thereby, we hope, avoiding an RFC failing because enough people dislike one little part of it.)

To that end, we're looking for very high level feedback on this RFC:

https://wiki.php.net/rfc/pattern-matching

By "very high level," I mean, please, do not sweat specific syntax details right now. That's a distraction. What we're asking right now is "which of these patterns should we spend time sweating specific syntax details on in the coming weeks/months?" There will be ample time for detail bikeshedding later, and we've identified a couple of areas where we know for certain further syntax development will be needed because we both hate the current syntax. :-)

If you want to just read the Overview section for a survey of the possible patterns and our current recommendations, you likely don't need to read the rest of the RFC at this point. You can if you want, but again, please stay high-level. Our goal at the moment is to get enough feedback to organize the different options into three groups:

1. Part of the RFC.
2. Secondary votes in the RFC.
3. Future Scope.

So we know where to focus our efforts to bring it to a proper discussion.

Thank you all for your participation.

--
Larry Garfield
larry@garfieldtech.com

Thank you!

$var is *; // Matches anything, more useful in the structure patterns below.

maybe also consider:

$var is mixed; // Matches anything, more useful in the structure patterns below.

// Array application, apply a pattern across an array
$foo is array<strings>; // All values in $foo must be strings
$foo is array<int|float>; // All values in $foo must be ints or floats

+1

Regards
Thomas

This definitely looks like a powerful feature I'm looking forward to.

If property/param/return guards are implemented, do you see them eventually
replacing the property/param/return types we have nowadays?
Asking for a friend.

Hello, peoples.

To that end, we're looking for very high level feedback on this RFC:

https://wiki.php.net/rfc/pattern-matching

As I started reading I starting thinking of "whatabouts" based on my
experience with pattern matching in other languages, and as I skimmed
the RFC I found each of them being addressed. I'm looking forward to this.

If you want my feedback about match() "is" placement, I can see the
benefits of both, and they don't look mutually exclusive, since the "is"
effectively just distributes over the branches to produce the inline
alternative; with that interpretation it's just an error to have "is" in
the top position and something other than a type pattern in any branch
because it would be equivalent to "is <not a type pattern>".

I suspect the case where one is matching against a list of types will
turn out to be quite common, so if "match ($somevar) is {" weren't
implemented there'd soon be people asking for something equivalent to
save them typing "is" over and over.

One thing to note is that if "is" were to be in the top position, it
means every branch has to be a type pattern, which means instead of
"default" the catch-all branch would be "mixed". (That's a question:
won't the branches of "match($var)is{" need to range over every possible
type?)

One tiny note about BC breakage:

If the as keyword is adopted as well, that will also be a new global
keyword.

"as" is already a global keyword (as in "foreach($arr as $e)"). So
that's not such a problem after all.

Hello, peoples.

Ilija and I have been working on and off on an RFC for pattern matching
since the early work on Enumerations. A number of people have noticed
and said they're looking forward to it.

Hi Larry,

I haven't time to read through the full RFC at the moment, but a couple of thoughts:

As Andreas says, we should be careful not to pre-empt things that might be added to the type system in general, and end up with incompatible syntax or semantics. That particularly applies to the generic-like array<int> syntax, which is quite likely to end up in the language in some form.

The "weak-mode flag" seems useful at first glance, but unfortunately PHP has multiple sets of coercion rules, and some are ... not great. It's also not immediately obvious which contexts should actually perform coercion, and which should just assert that it's possible (e.g. match($foo) is { ~int => (int)$foo } feels redundant). So I think that would need its own RFC to avoid being stuck with something sub-optimal.

Similarly, the "as" keyword has potential, but I'm not sure about the naming, and whether it should be more than one feature. Asserting a type, casting between types, and de-structuring a type are all different use cases:

$input = '123'; $id = $input as int; // looks like a cast, but actually an assertion which will fail?
$handler as SpecialHandler; // looks like an unused expression, but actually an assertion?
$position as [$x, $y]; // looks like its writing to $position, but actually the same as [$x, $y] = $position?

It's worth noting that in languages which statically track the type of a variable, "$foo = $bar as SomeInterface" is actually a type of object cast; but in PHP, it's the value that tracks the type, and interfaces are "duck-typed", so it would be equivalent to "assert($bar is SomeInterface); $foo = $bar;" which isn't quite the same thing.

Regards,

Rowan Tommins
[IMSoP]

Ilija and I have been working on and off on an RFC for pattern matching since the early work on Enumerations. A number of people have noticed and said they're looking forward to it.

Hi Larry, I have definitely been looking forward to this. Perhaps more
so than property hooks and avis.

By "very high level," I mean, please, do not sweat specific syntax details right now. That's a distraction. What we're asking right now is "which of these patterns should we spend time sweating specific syntax details on in the coming weeks/months?" There will be ample time for detail bikeshedding later, and we've identified a couple of areas where we know for certain further syntax development will be needed because we both hate the current syntax. :-)

I think that a lot of this would be best broken up. Although much of
it is aimed towards the same general idea, a lot of the pieces have
specific use cases and special syntax additions. Overall I think this
rfc should be simplified to just pattern matching with the is
keyword with the patterns limited to what can be declared as property
types (DNF types) and future scoping everything else. Maybe possibly
with the addition of 1 or 2 of the top requested is pattern matching
capabilities as secondary votes.

1. as
is and as have different responsibilities. I'm guessing the idea
   is to keep them in sync. But I would still like to see this as a
   future scope with a separate rfc. I do like the idea, and believe it's
   much needed. But I think the pattern matching portion is overshadows
   the as portion causing it not to get as much attention as far as
   discussion and analysis goes. Especially if the idea is to sync them,
   then that makes as just as big of an addition as is

For example, what if instead, a generally prefered solution/syntax
were variable types, something like:
var Foo&Bar $my_var = $alpha->bravo;
Although casting and declaring are 2 separate things. This seems like
it would accomplish the same thing without the extra keyword, with the
exception of casting being inline. How much would it get used if both
were added? Would one then become an "anti-pattern"?

2. Literal patterns
   Again a really nice addition. Love it and likely will be loved by
   many. Although, it definitely deserves its own separate discussion.
   Looking at typescript which has both enums and literal types (although
   vastly different in php) caused what was once considered a nice
   feature to be black listed by many. Also note how typescript separates
   type land and value land. Maybe worth considering.

3. Wild card
   Has already been marked as not necessary it looks like and replaced by mixed.

4. Object matching
   Absolutely a separate rfc please. Definitely needs discussion. Could
   intersect another potentially preferred solution like type aliases.
   Sending one or the other into anti-pattern world.
   Maybe a solution similar to this would be preferred:

type MyType = Foo&Bar
$foo = $bar as MyType|string

Or maybe not, either way I think it needs its own spotlight.

5. Array sequence patterns
   More in depth discussion needed. Not sure how often this comes up as a
   structure people want to check against, but it can definitely be done
   in user land with array slices. Even though it might be nice for
   completion's sake, it may not be worth it if there's not high demand
   for it. If at all could be grouped with associative array patterns.

6. Associative array patterns
   Love to have this one, but it also seems like a small extension or
   conflicting with array shapes. Also potentially conflicts with
   generics (which may or may not ever be a thing) but still let's give
   it the attention it needs. Maybe group with array shapes as well.

7. Array shapes
   Same as above

8. Capturing values out of a pattern and binding them to variables if matched
   Ok I think that's stepping a bit far out of scope. Maybe is should
   simply check and not have any side effects.

9. match .. is
   Nice shorthand to have but i'd rather not see short hands forced in as
   an all or nothing type thing as was done with property hooks. I'd also
   argue that maybe short hands should not be added until a feature has
   been around for at least one release and is generally accepted. That
   way we're not using up syntaxes and limiting the ability to add other
   syntax features without breaking backwards compatibility. Keep in mind
   that the is functionality alone allows this (or at least it should)
   and a shorter version may or may not be desired.

match(true) {
  $var is Foo => 'foo',
  ...
}

** This is not an order of preference by any means, just listed as
seen in the rfc. **

I'll stop there, and hope the message is received. In summary I would
be plenty grateful for just being able to check against DNF types
initially with support for more pattern types in the near or distant
future.

I think array shapes and literal types are the only ones I'd hope for
a sooner rather than later follow up rfc targeted hopefully for the
same release. Maybe even as secondary votes. The others I'm ok with
waiting for and would rather see follow up rfcs on them as time
permits.

Hi Larry,

Hello, peoples.

Ilija and I have been working on and off on an RFC for pattern matching since the early work on Enumerations. A number of people have noticed and said they're looking forward to it.

It's definitely not going to make it into 8.4, but we are looking for early feedback on scoping the RFC. In short, there's a whole bunch of possible patterns that could be implemented, and some of them we already have, but we want to get a sense of what scope the zeitgeist would want in the "initial" RFC, which would be appropriate as secondary votes, and which we should explicitly save-for-later. The goal is to not spend time on particular patterns that will be contentious or not pass, and focus effort on fleshing out and polishing those that do have a decent consensus. (And thereby, we hope, avoiding an RFC failing because enough people dislike one little part of it.)

To that end, we're looking for very high level feedback on this RFC:

https://wiki.php.net/rfc/pattern-matching

By "very high level," I mean, please, do not sweat specific syntax details right now. That's a distraction. What we're asking right now is "which of these patterns should we spend time sweating specific syntax details on in the coming weeks/months?" There will be ample time for detail bikeshedding later, and we've identified a couple of areas where we know for certain further syntax development will be needed because we both hate the current syntax. :-)

If you want to just read the Overview section for a survey of the possible patterns and our current recommendations, you likely don't need to read the rest of the RFC at this point. You can if you want, but again, please stay high-level. Our goal at the moment is to get enough feedback to organize the different options into three groups:

1. Part of the RFC.
2. Secondary votes in the RFC.
3. Future Scope.

So we know where to focus our efforts to bring it to a proper discussion.

Thank you all for your participation.

Is is already a really nice RFC, even if not finished yet. Also haven't
fully read it yet.
Thank you for all your work and time put into it!

I do have some questions:

• For the generics-like pattern I do agree with the others that this
  might be dangerous for the future if we (hopefully) are going at it.

• Capturing values out of a pattern and binding them to variables if
  matched.

Where this is very helpful especially with match, from the syntax I
would read it as a condition only.

$p is Point {x: 3, y: $y}; // read as $p->y === $y but it's $y = $p->y

But this is described differently

$p is Point {y: 37, x:@($x)};

I think it would be more readable on switching the logic (somehow). like:

$p is Point {x: 3, y: $y}; // $p->y === $y
$p is Point {x: 3, y:=> $y}; // $y = $p->y

• Regex pattern

This one is interesting as well ... but I would expect native regex
syntax first before introducing it as part of a different RFC. Similar
as generics.

Following up I would expect something like this:

    $re = /.*/;  // RegEx object
    $matches = $re->match($v); // preg_match
    $v is $re; // used in pattern matching

which opens up another question: Could we have an interface allowing
objects to match in a specific way?

    interface Matchable {
        public function match(mixed $value): bool;
    }

Thanks for working on it!

Marc

Ilija and I have been working on and off on an RFC for pattern matching since the early work on Enumerations. A number of people have noticed and said they're looking forward to it.

Hello Larry.

Thanks for this Juicy proposal.

I agree that this proposal should be proposed as a whole. If we break
it down into smaller parts, there is a chance some features will not
pass. I will show you that the range pattern and regex pattern have
greater value than what you think, and they must be placed together
with the literal pattern (in Core patterns section, not in Possible
patterns section). I don't want these patterns to fail in the poll.

I don't know the line between "high level" and beyond. I hope that
whatever I discuss here is still "high level".

1. Is there any chance of is not or isnot? I am tired
   looking this ugly code: !($foo instanceof Bar). If there is,
   there should be a restricted version of pattern: no variable binding.
   It doesn't make sense if the binding happens but the pattern fails.

2. ..= and ..< make people have to remember what the left
   side is: is it greater-than or greater-than-equal. What if those
   operators are replaced with =..= and <..=? We don't have
   to align with other languages if they have weaknesses.

3. There are "between" and > operators explicitly shown in the
   proposal (in Range pattern section). I assume that >=, <,
   <= implicitly included. What about the % operator, is it
   also included? % is not directly produces boolean, but it can
   simplify pattern. Note that, we must include additional rules: if
   produced number is 0 (zero) then it will be converted to
   true, otherwise false.

$foo = 2024; // leap year
$foo is %4; // true

$bar = 2025; // not a leap year
$bar is %4; // false

// furthermore:
$baz is array<%4>; // true if all its members are leap year

4. There are numeric range patterns explicitly shown in the proposal.
   Hopefully there are also string range patterns.

$birthdate is "2000-01-01 00:00:00" <..< "2019-12-31 23:59:59";
$dateOfDeath is <"1980-01-01";
$name is "larry " =..< "larry!"; // true if first name is "larry"

I have no idea about string range patterns for array, since it causes
error. If there is currently no solution, hopefully we don't abandon
string range patterns entirely. The same case also occurs with numeric
range patterns for array.

5. It is great that regular expression native syntax is now a first
   class citizen in php (at least for pattern matching). I found there
   are 2 drawbacks in this case: loss of flexibility and repeated
   identical patterns. These things are not found in string based regular
   expression.

// native syntax
$foo is /^https:\/\/(?<hostname>[^\/]*)/;

// string based: we can use any valid char as delimiter,
// as long as it is not used in the pattern.
$pattern = "/^https:\/\/(?<hostname>[^\/]*)/";
$pattern = "|^https://(?<hostname>[^/]*)/|";    // valid!
$pattern = "@^https://(?<hostname>[^/]*)/@";    // valid!

// ----------------------

// native syntax
$foo is /^https:\/\/(?<hostname>[^\/]*)/ | StringBox{value:
/^https:\/\/(?<hostname>[^\/]*)/};

// string based: RE stored in variable/constant can be used as many as we need
$pattern = "|^https://(?<hostname>[^/]*)/|";
$foo is @RE($pattern) | StringBox{value: @RE($pattern)};
// 1st pattern is scalar string, 2nd is string encapsulated in a class

// furthermore
use GenericPattern as GP;
class Person {
    public string $firstName is @RE(GP::NAME_PTRN);
    public string $lastName is @RE(GP::NAME_PTRN);
// ...
}

Hopefully, string based regular expression is also supported.
Honestly, if I could choose whether I should support native or
string-based syntax, I would choose to support string-based, as long
as native syntax is not yet fully supported in general.

@RE() is just an illustration on how to use variable as a
regular expression in the pattern. It is stated that @() will be
used in arbitrary expressions. Correct me if I'm wrong, regexp are one
of the things in programming that cannot be manipulated or participate
in manipulation with other parties, even with fellow regexp. Regexp
must be used alone. That is why we need dedicated syntax for regexp.

6. It is shown that type pattern, literal pattern, class constant
   pattern, and expression pattern can be used to form a compound
   pattern. Hopefully, the range pattern and regex pattern have the same
   luxury. Furthermore, hopefully they can be mixed.

$foo is 2000 =..= 2100 & %4; // leap year in 21st century

class person {
    public string $firstName is /LENGTH_PTRN/
        & /FORBIDDEN_CHARS_PTRN/
        & /FORBIDDEN_WORDS_PTRN/;

    public string $lastName is @RE(GP::LENGTH_PTRN)
        & @RE(GP::FORBIDDEN_CHARS_PTRN)
        & @RE(GP::FORBIDDEN_WORDS_PTRN);


    //  these are hard to maintain
    public string $firstName is @RE(GP::COMPLEX_NAME_PTRN);
    public string $lastName is @RE(GP::COMPLEX_NAME_PTRN);
}

7. I noticed that ```as``` is tightly coupled with exception. Can we
suppress this exception with ```??```?

// it is weird to see this statement (as show in the proposal)
$value = $foo as Foo {$username, $password};

// these statements are more make sense
$foo as Foo {$username, $password};
$foo is Foo {$username, $password} ?: throw new Exception();

// if it can be suppressed, "as" is more valuable than what people think.
$newRect = $rect as Rectangle{width: <=10, height: <=5} ?? new
Rectangle(width: 10, height: 5);

8. Is there any type checking for object property pattern?

class Circle {
public int $radius;
}

// this statement will always fails unless there is type checking
$circle is Circle{radius: "10"};

~~~~~

4 of the 8 points I discussed above are related to range pattern and
regex pattern. Both are used daily. From my point of view, literal
pattern is no more special than range pattern and regex pattern. IMO,
both should be placed in Core patterns section, not in Possible
patterns section.

Regards, Hendra Gunawan.

Ilija and I have been working on and off on an RFC for pattern matching since the early work on Enumerations. A number of people have noticed and said they're looking forward to it.

[THIS REPLY IS FOR THE CONVENIENCE OF https://externals.io READERS
ONLY. SORRY FOR THE UNPLEASANT DISPLAY]

Hello Larry.

Thanks for this Juicy proposal.

I agree that this proposal should be proposed as a whole. If we break
it down into smaller parts, there is a chance some features will not
pass. I will show you that the range pattern and regex pattern have
greater value than what you think, and they must be placed together
with the literal pattern (in Core patterns section, not in Possible
patterns section). I don't want these patterns to fail in the poll.

I don't know the line between "high level" and beyond. I hope that
whatever I discuss here is still "high level".

1. Is there any chance of is not or isnot? I am tired
   looking this ugly code: !($foo instanceof Bar). If there is,
   there should be a restricted version of pattern: no variable binding.
   It doesn't make sense if the binding happens but the pattern fails.

2. ..= and ..< make people have to remember what the left
   side is: is it greater-than or greater-than-equal. What if those
   operators are replaced with =..= and <..=? We don't have
   to align with other languages if they have weaknesses.

3. There are "between" and > operators explicitly shown in the
   proposal (in Range pattern section). I assume that >=, <,
   <= implicitly included. What about the % operator, is it
   also included? % is not directly produces boolean, but it can
   simplify pattern. Note that, we must include additional rules: if
   produced number is 0 (zero) then it will be converted to
   true, otherwise false.

$foo = 2024; // leap year
$foo is %4; // true

$bar = 2025; // not a leap year
$bar is %4; // false

// furthermore:
$baz is array<%4>; // true if all its members are leap year

4. There are numeric range patterns explicitly shown in the proposal.
   Hopefully there are also string range patterns.

$birthdate is "2000-01-01 00:00:00" <..< "2019-12-31 23:59:59";
$dateOfDeath is <"1980-01-01";
$name is "larry " =..< "larry!"; // true if first name is "larry"

I have no idea about string range patterns for array, since it causes
error. If there is currently no solution, hopefully we don't abandon
string range patterns entirely. The same case also occurs with numeric
range patterns for array.

5. It is great that regular expression native syntax is now a first
   class citizen in php (at least for pattern matching). I found there
   are 2 drawbacks in this case: loss of flexibility and repeated
   identical patterns. These things are not found in string based regular
   expression.

// native syntax
$foo is /^https:\/\/(?<hostname>[^\/]*)/;

// string based: we can use any valid char as delimiter,
// as long as it is not used in the pattern.
$pattern = "/^https:\/\/(?<hostname>[^\/]*)/";
$pattern = "|^https://(?<hostname>[^/]*)/|";    // valid!
$pattern = "@^https://(?<hostname>[^/]*)/@";    // valid!

// ----------------------

// native syntax
$foo is /^https:\/\/(?<hostname>[^\/]*)/ | StringBox{value:
/^https:\/\/(?<hostname>[^\/]*)/};

// string based: RE stored in variable/constant can be used as many as we need
$pattern = "|^https://(?<hostname>[^/]*)/|";
$foo is @RE($pattern) | StringBox{value: @RE($pattern)};
// 1st pattern is scalar string, 2nd is string encapsulated in a class

// furthermore
use GenericPattern as GP;
class Person {
    public string $firstName is @RE(GP::NAME_PTRN);
    public string $lastName is @RE(GP::NAME_PTRN);
// ...
}

Hopefully, string based regular expression is also supported.
Honestly, if I could choose whether I should support native or
string-based syntax, I would choose to support string-based, as long
as native syntax is not yet fully supported in general.

@RE() is just an illustration on how to use variable as a
regular expression in the pattern. It is stated that @() will be
used in arbitrary expressions. Correct me if I'm wrong, regexp are one
of the things in programming that cannot be manipulated or participate
in manipulation with other parties, even with fellow regexp. Regexp
must be used alone. That is why we need dedicated syntax for regexp.

6. It is shown that type pattern, literal pattern, class constant
   pattern, and expression pattern can be used to form a compound
   pattern. Hopefully, the range pattern and regex pattern have the same
   luxury. Furthermore, hopefully they can be mixed.

$foo is 2000 =..= 2100 & %4; // leap year in 21st century

class person {
    public string $firstName is /LENGTH_PTRN/
        & /FORBIDDEN_CHARS_PTRN/
        & /FORBIDDEN_WORDS_PTRN/;

    public string $lastName is @RE(GP::LENGTH_PTRN)
        & @RE(GP::FORBIDDEN_CHARS_PTRN)
        & @RE(GP::FORBIDDEN_WORDS_PTRN);


    //  these are hard to maintain
    public string $firstName is /COMPLEX_NAME_PTRN/;
    public string $lastName is @RE(GP::COMPLEX_NAME_PTRN);
}

7. I noticed that as is tightly coupled with exception. Can we
   suppress this exception with ???

// it is weird to see this statement (as show in the proposal)
$value = $foo as Foo {$username, $password};

// these statements are more make sense
$foo as Foo {$username, $password};
$foo is Foo {$username, $password} ?: throw new Exception();

// if it can be suppressed, "as" is more valuable than what people think.
$newRect = $rect as Rectangle{width: <=10, height: <=5} ?? new
Rectangle(width: 10, height: 5);

8. Is there any type checking for object property pattern?

class Circle {
    public int $radius;
}

// this statement will always fails unless there is type checking
$circle is Circle{radius: "10"};

4 of the 8 points I discussed above are related to range pattern and
regex pattern. Both are used daily. From my point of view, literal
pattern is no more special than range pattern and regex pattern. IMO,
both should be placed in Core patterns section, not in Possible
patterns section.

Regards, Hendra Gunawan.

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

Le jeudi 20 juin 2024, 19:38:40 UTC+2 Larry Garfield a écrit :

To that end, we're looking for very high level feedback on this RFC:

https://wiki.php.net/rfc/pattern-matching

Hello,

Thank you for this RFC.

Sorry if that’s a bit focused on syntax, but I’m really concerned by the binding syntax.
I would totally expect both these codes to do the same thing:

if ($o is Class{prop: 3}) {

and:

$x = 3;
if ($o is Class{prop: $x}) {

I’ve seen someone else in the discussion propose to invert the logic between binding and use a variable and I agree, it’s the binding/capture which should have the special syntax.
Either another operator than ':', I’ve seen '=>' proposed. Or any other idea to differentiate it.

'=>' would allow to combine match and capture like this:

$o is Class{prop: int => $y}

Côme