Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:107598 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 39655 invoked from network); 21 Oct 2019 16:50:55 -0000 Received: from unknown (HELO php-smtp3.php.net) (208.43.231.12) by pb1.pair.com with SMTP; 21 Oct 2019 16:50:55 -0000 Received: from php-smtp3.php.net (localhost [127.0.0.1]) by php-smtp3.php.net (Postfix) with ESMTP id B9D6F2CA153 for ; Mon, 21 Oct 2019 07:36:35 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp3.php.net X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS3215 2.6.0.0/16 X-Spam-Virus: No Received: from mail-ot1-x32b.google.com (mail-ot1-x32b.google.com [IPv6:2607:f8b0:4864:20::32b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by php-smtp3.php.net (Postfix) with ESMTPS for ; Mon, 21 Oct 2019 07:36:35 -0700 (PDT) Received: by mail-ot1-x32b.google.com with SMTP id s22so11170682otr.6 for ; Mon, 21 Oct 2019 07:36:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=t5dhk0ElF5zJ43u62BB/3C1L8tV7AFK3NFk38RFKeTA=; b=Pb4GlyZKvP+aeMegcjnO1DwiWtWptqbirNjC5HEhFZhcpzQDHy26R3LhYepcEOccdP EzdUrnJ4Xp4332bA2C9cyiplV18Sv4jOqTgYpRmngzbP1OyTc0S73507HAfVRrGpxAid qIxEoxneGb3d3zrkPYHnsTQo8p+5xhCOT229V10eTzKyME7mK19+ClFjZy+ZN9uljHH0 iF/Rp/4YQUHVQkztVPguXF/hozYUnPlucaSFZ2Qi8zAWrCIaB6yQfHqj9yg30JPcOoyy u/LjysXhZniK4Le9ML6V9yS20qRS5RoCAyw2UMMC7b2LskSclFCmBLhOQ30WvysnDM4W T2Cw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=t5dhk0ElF5zJ43u62BB/3C1L8tV7AFK3NFk38RFKeTA=; b=LmRJmp0VfKqlrsRncff4fC7Iv2OaNUcwieq6Wb8QHn34Hw4WBttswAbEFZUjn4OYNS WiI/BoFcmaCmjRlS/+53lhnzS3x7i+/DcccbyKw3lsY7FRkjllWfHqrEM+jgNJIxy/FJ brvV/avkoEOHF3v7hkz4xQNV/wufwj1GAEYplop+BeZ6dsANXF/pNs3gmxEveYJ45IO/ xp7oqNTsUUl5+nAXCwimdlsQN8xIctnUCT9SFJImOyv88IWdplsghx9iZ+xdsOLHYBd7 A+RX9nclrTNUBmLIBQyjcjGXzcODWz8j4V8oYVUxKyUq4JTBcEKoPB0ssL2+Ef+zPVkL UgFw== X-Gm-Message-State: APjAAAWfHUDmWTerW3n7CphdU27PUDlsimPq1m/IHTqTW8ddNGzH2P4c dnyoRtr6Fea1mlHXDdAgTNLCokQ+08hHWqWFFNE= X-Google-Smtp-Source: APXvYqxKfSU16ydhqtCRN0EHzdS+ZyadCaJoWBnwmCAa8I6dbi2ZjlFWwBo/CDnx8Ox1VIBuxakSUCehQGABvPVVTZY= X-Received: by 2002:a9d:2a8:: with SMTP id 37mr17995184otl.163.1571668594426; Mon, 21 Oct 2019 07:36:34 -0700 (PDT) MIME-Version: 1.0 References:

In-Reply-To: Date: Mon, 21 Oct 2019 21:36:27 +0700 Message-ID: To: Rowan Tommins Cc: PHP internals Content-Type: multipart/alternative; boundary="00000000000046874005956c9c05" X-Envelope-From: Subject: Re: [PHP-DEV] 'switch-expression' and the 'type guard' unary operator demo From: webdevxp.com@gmail.com (Kosit Supanyo) --00000000000046874005956c9c05 Content-Type: text/plain; charset="UTF-8" Hi Rowan I'm not sure is the right syntax for type guards, but it's possible > we'd want a different syntax for new switch/match functionality anyway. I've decided to change the syntax to `(: foo)`. It may look weird at frist but it is able explain why I think this syntax is more appropriate. Because PHP already uses `:` to specify return type of functions so `(: foo)` syntax can be seen as a way to specifying return type of expressions. And it can be put into the same visual category of cast operators. $a = (int)$b; // filter $c = (: int)$d; // guard This syntax choice may not satisfy everyone's taste but at least it is explainable. So now there's 2 choices `` and `(: foo)`. And more choices are welcome from anyone who think type guard should be a new feature. For instance, using a placeholder for the value being tested, like $$ (a > common > choice in other languages is _, but that's a valid and commonly used > function name): About that, I'm working on a different approach which I would like to show you after I finished the next demo :) Regards On Mon, Oct 21, 2019 at 8:52 PM Rowan Tommins wrote: > Hi Kosit, > > On Sun, 20 Oct 2019 at 16:20, Kosit Supanyo > wrote: > > > You can recognize the difference of those by looking for `=>` right? But > > the parser generator (bison) cannot do that in LR mode (it maybe can in > GLR > > mode but I'm sure that would be unacceptable due to performance > losses/more > > memory usage). So workarounds have to be used. I did it by simply return > > different tokens from the lexer base on previous token before `switch`. > >> > >> > > > Thanks for clarifying, I thought it might be something like that. > > > > > > * Different comparisons applied to the same variable/expression, e.g. > >> match($user->getScore()) { case <0 => foo(), case >100 => bar(), default > >> => baz() } > > > > > > I'd thought about that feature too. But since I also introduced type > guard > > operator which uses `<` token it would have parser conflicts and simple > > workarounds cannot apply. > > > > > > I'm not sure is the right syntax for type guards, but it's possible > we'd want a different syntax for new switch/match functionality anyway. For > instance, using a placeholder for the value being tested, like $$ (a common > choice in other languages is _, but that's a valid and commonly used > function name): > > match ( $user->getScore() ) { > $$ < 0, $$ > 100 => foo(), > $$ < 10 => bar(), > default => baz() > } > > You could also allow the placeholder in the opening clause to define the > same operation for each case: > > match ( $user->getScore() < $$ ) { > 0, default => foo(), > 10 => bar(), > 100 => baz() > } > > > Regards, > -- > Rowan Tommins > [IMSoP] > --00000000000046874005956c9c05--