Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:109809
MIME-Version: 1.0
References: <CAPyj-LDfdATXFD+dc5AY9EqWWxgf8LP1joD2fzvm==1gUoN35A@mail.gmail.com>
 <CAPyj-LAM7yS0U0TZY9pLyuysuz3KikHjegZ6ESYPLTNfT02yPQ@mail.gmail.com> <CA+kxMuSOMuPpkJScf1TeqCvCeD0An8LCsMa=ONL2FQ+s+J1cpg@mail.gmail.com>
In-Reply-To: <CA+kxMuSOMuPpkJScf1TeqCvCeD0An8LCsMa=ONL2FQ+s+J1cpg@mail.gmail.com>
Date: Thu, 23 Apr 2020 15:18:59 +0200
Message-ID: <CAPyj-LB3upRqoLAO76Y9jUzs+0qcXv4zfj-fbeZC_bY2Mycikg@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [PHP-DEV] Re: [DISCUSSION] Match expression
From: tovilo.ilija@gmail.com (Ilija Tovilo)

Hi Dan

> I don't think PHP can guarantee to detect duplicate conditions

This warning is only shown if duplication is guaranteed, namely when a
jumptable is generated. Which also makes the check fairly cheap.

> Would the duplicate condition* below be detected?

No, as jumptables are only generated when the conditions are all
integers or all strings. It's worth noting there are some cases that
could be detected but aren't. For example:

match ($x) {
    1, 1 => { echo $x; }
}

This is because we don't generate a jumptable when there are less than
5 integer conditions. Because of this inconsistency I'm not sure if we
should just remove the warning. As you mentioned, it could be
intentional in some cases. Tyson also mentioned that some constants
are platform dependent which would make it warn on some platforms but
not on others.

> Are the match conditions guaranteed to be called in order that they
> are defined? I'm guessing yes, but it doesn't appear to be mentioned.

They are, yes. The behavior here should be equivalent to the switch.
It wouldn't hurt mentioning that in the RFC.

> I would prefer having an explicit fall-through statement, for the
> relatively rare cases when fall-through is needed. Is there a strong
> reason to not add it now?

I wouldn't call it a strong reason but we'd have to be more careful
with fallthrough when we implement pattern matching.

match ($x) {
    let $y @ 10..<20 => {
        fallthrough;
    },
    let $z @ 0..<10 => {
        // Pattern $z was never bound
    }
}

Other than that, I just don't think it's awfully useful but that's of
course a matter of opinion. But there's nothing directly stopping us
from adding it. For me personally it's not a priority.

> Is there any protection against people doing odd stuff with
> references*, or is that their own problem if they choose to do that?

We have some tests for references, we couldn't discover any weird or
surprising behavior (although we could definitely use more tests
here).

Ilija