Re: [RFC] Pattern Matching

Hi, > 1. match() statements. There's two ways we could do this: All-branches, or individual > branches. This is particularly important as, in practice, we expect match() to be the most common > use of patterns. I prefer to have one syntax. The most flexible one is individual arms. And to me it also looks more clean from the functional side. If we support both we should also disallow the use of mixing all arms and individual arms. Thus this syntax should return an error. $result = match ($somevar) is { // Error! is Foo => 'foo', is Bar => 'bar', is Baz|Beep => 'baz', }; > Positional array patterns. How picky should the pattern matching be for list-esque arrays? > There's 3 options listed in the RFC as possible ways forward, so I won't repeat them here > but just provide a link: > > > https://wiki.php.net/rfc/pattern-matching#positional_array_enforcement From a cost perspective it would be best to keep it to a minimum. But array’s exist in different styles where it matters to have at least a few edge-cases covered. Especially when converting between data formats (Serialise, JSON, ..) I would personally discourage to return true with the following cases: Given: $a = ['a', 'b', 'c']; $a is [2 => 'c', 0 => 'a', 1 => 'b']; Should return false, because when converting to other data formats. The style will change from numerical to key'ed (associative style). The same applies to the inverse. Though given: $a = ['a', 'b', 'c']; $a is [0 => 'a', 1 => 'b', 2 => 'c']; Should return true, because they keep the numerical order. And when converted it will be the same. > 3. Do we want to have a pattern for "match an object's properties without specifying > what type the object has to be?" If so, what syntax should it be? Just omitting the class name > (producing $o is {x: 1} ) is not possible. We tried. :-) Options > include: > > $o is _(x: 1) > $o is object(x: 1) I am not a favour of using shorthands. They tend to make code more difficult to read and understand.  Thus $o is object(x: 1) is what I suggest as well. 4. >  The variable pinning syntax. There's been some concerns about it being non-obvious, > which is valid. The main argument for it is "it's what Ruby does", which is not the > most compelling argument, but it's not invalid. I strongly agree that the the ^ is not a good choice. It is difficult to understand,I personally think pinning at all is not important. Though if we proceed forward on this {$x} would make most sense since it is more in line with string interpolation syntax. And like you mentioned it opens more possibilities. Regards, Jordi