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
