Hi Claude,

On 04.02.25 11:10, Claude Pache wrote:


Le 4 févr. 2025 à 10:34, Dmitry Derepko <xepo...@gmail.com> a écrit :

Hi, Claude!

On Feb 4, 2025, at 11:44 AM, Claude Pache <claude.pa...@gmail.com> wrote:

Hi,

One issue to resolve is how to interpret:

```php
$x = match {
  preg_match('/a/', 'a') => "will it be matched ..."
 , default => "... or not?"
};
```

—Claude

I wouldn’t discuss it there because the proposal is only about short syntax.
So making “match” work in different way is not a goal for the change.

It must work as full form “match(true)”: strict match, which is "===“.
If you’re going to use non-strict comparison check “switch” operator: https://3v4l.org/tHkJu
Anyway, as for me it should be another thread. Thanks!

Hi Dmitry,

The issue absolutely belong to a thread discussing making “match (true) {}” equivalent to “match {}”.

agree


It doesn’t matter what is logical or simple, you have also think about what is intuitive or, conversely, confusing.

Of course it matters what is logical as a logical rule is much better to remember and document as a rule with tons of exceptions.



With `match (true) { $foo => ... }`, it is clear you are comparing  $foo with the literal value `true`.

With `match { $foo => ... }`, it is not intuitive at all that you are *not* just checking the condition $foo, but rather you are comparing $foo with some default literal value. The difference matters.

Therefore, I think it is a bad idea to make `match (true) { }` equivalent to `match { }`.

No, for me this isn't logical and it's going to be an exception which is harder to follow.

Given your example from above actually shows me that this would hide an error case (or better makes the error case look like the usual one in this case)

Additionally, if you really what to compare empty vs. non empty you can use empty to make it explicit.


Marc

Attachment: OpenPGP_0x3936ABF753BC88CE.asc
Description: OpenPGP public key

Attachment: OpenPGP_signature.asc
Description: OpenPGP digital signature

Reply via email to