Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:107589
MIME-Version: 1.0
References: <CAP=w73VJ6pxstVzyfFkOp=esX7ne-LosWP1Eb8Ac0u-JeROPRA@mail.gmail.com>
 <bd36083e-a84d-69e1-725c-7b026a009be1@gmail.com>
In-Reply-To: <bd36083e-a84d-69e1-725c-7b026a009be1@gmail.com>
Date: Sun, 20 Oct 2019 22:19:56 +0700
Message-ID: <CAP=w73XqXHX2YS+OZ9KPcp5gO6xXmr=qm=ZGWXcS6iMTksDyuQ@mail.gmail.com>
To: Rowan Tommins <rowan.collins@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000004169ff0595591abc"
Subject: Re: [PHP-DEV] 'switch-expression' and the 'type guard' unary operator demo
From: webdevxp.com@gmail.com (Kosit Supanyo)

--0000000000004169ff0595591abc
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Rowan

Thank you for your reply.

Was this restriction added to make the implementation easier, or because
> you thought it was a useful feature?
>

This is not a restriction but a result of implementation workarounds. Let's
see:

switch ($x) {
    case 1:
        echo "ONE\n";
        break;
    case 2:
        echo "TWO\n";
        break;
}

vs

switch ($x) {
    case 1 =3D> print "ONE\n",
    case 2 =3D> print "TWO\n",
};

You can recognize the difference of those by looking for `=3D>` 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`.
https://github.com/webdevxp/php-src/blob/switch-expression/Zend/zend_langua=
ge_scanner.l#L1460
https://github.com/webdevxp/php-src/blob/switch-expression/Zend/zend_langua=
ge_scanner.l#L1247

And use that different tokens to define rules in the parser definition so
it won't have any shift/reduce conflicts.
https://github.com/webdevxp/php-src/blob/switch-expression/Zend/zend_langua=
ge_parser.y#L443

https://github.com/webdevxp/php-src/blob/switch-expression/Zend/zend_langua=
ge_parser.y#L1107

* Different comparisons applied to the same variable/expression, e.g.
> match($user->getScore()) { case <0 =3D> foo(), case >100 =3D> bar(), defa=
ult
> =3D> 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.

$v =3D switch ($x) {
    case < <int>$y =3D> 1, // shift/reduce conflict here
};

But if type guard was removed or changed to use another token like `(:int)`
that feature would be easy to implement because currently `ZEND_CASE`
opcode has `extended_value` unused so we can use it to store operator data.

Cheers

>
>

On Sun, Oct 20, 2019 at 9:15 PM Rowan Tommins <rowan.collins@gmail.com>
wrote:

> Hi Kosit,
>
> There's some really interesting ideas in here, thanks for sharing them.
>
>
> On 19/10/2019 17:40, Kosit Supanyo wrote:
> > Like function declaration and function expression in JavaScript, if
> > `switch` appears as first token at statement level it will be recognize=
d
> as
> > statement but if `switch` is in expression context it will be
> > switch-expression.
> >
> > switch ($expr) {
> >      case $cond1 =3D> $result1,
> >      case $cond2 =3D> $result2,
> >      case $cond3 =3D> $result3,
> >      default =3D> $default_result,
> > };
> > // Parse error: syntax error, unexpected '=3D>' (T_DOUBLE_ARROW)
> >
> > But this is OK.
> >
> > !switch ($expr) {
> >      case $cond1 =3D> $result1,
> >      case $cond2 =3D> $result2,
> >      case $cond3 =3D> $result3,
> >      default =3D> $default_result,
> > }; // semicolon is still required because it is an expression
>
>
> This feels like an odd restriction to me, and one that as far as I'm
> aware PHP doesn't have anywhere else. For instance, it might be
> considered bad style, but it's possible to use a ternary operator as an
> abbreviated if statement:
>
> isset($_GET['logout']) ? $session->logout() : $session->extend();
>
> Was this restriction added to make the implementation easier, or because
> you thought it was a useful feature?
>
>
> > You can omit parenthesized expression which is shortcut to `switch
> (true)`.
> > This change applies to switch statement as well.
> >
> > $v =3D switch {
> >      case $x >=3D 0 && $x <=3D 100 =3D> 1,
> >      case $x >=3D 100 && $x <=3D 200 =3D> 2,
> >      default =3D> 3,
> > };
> >
> > switch {
> >      case $x >=3D 0 && $x <=3D 100:
> >          doSomething1();
> >          break;
> >      case $x >=3D 100 && $x <=3D 200:
> >          doSomething2();
> >          break;
> >      default:
> >          doNothing();
> >          break;
> > }
>
>
> This is an interesting idea, given that switch(true) is the documented
> way to do this right now. However, I've always felt switch(true) was
> rather limited in its advantage over if-elseif. I would prefer a syntax
> that reduced the boilerplate for:
>
> * Different comparisons applied to the same variable/expression, e.g.
> match($user->getScore()) { case <0 =3D> foo(), case >100 =3D> bar(), defa=
ult
> =3D> baz() }
> * Different values compared against the same expression using the same
> operator, e.g. match( $exception instanceOf ) { case FooException =3D>
> handleFoo(), case BarException =3D> handleBar() }
>
>
>
> > You can also use `return` and `throw` in result expression. I recalled
> some
> > languages have this feature (but I've forgotten what language). This
> > feature can be very handy and useful in many use cases.
> >
> > $x =3D 'd';
> > $v =3D switch ($x) {
> >      case 'a' =3D> 1,
> >      case 'b' =3D> 2,
> >      case 'c' =3D> return true,
> >      default =3D> throw new Exception("'$x' is not supported"),
> > };
>
>
> This seems confusing to me, because it mixes statements and expressions
> in a rather unusual way. The "return" case in particular seems ambiguous
> - if $v is visible outside the function, will it have a value assigned
> to it by the "return" branch, and if so what would that value be? I can
> imagine more use cases for the "throw" version, and it's reasonably
> obvious how it would behave, so it might be reasonable to have that one
> special case.
>
>
>
> > Additional feature in the demo patch is the 'type guard' unary operator
> > which is an operator that will perform type check on given value and
> throw
> > `TypeError` when type mismatch occurred, otherwise return the value as
> is.
> > It has the same precedence  as `new`.
> >
> > $a =3D 'This is a string';
> > $v =3D <int>$a; // TypeError: Value is expected to be int, string given
>
>
> This is a very interesting feature, although I think what would be even
> more useful would be syntax to check if something _can_ be cast, i.e.
> the same check you have here, but as an operator evaluating to boolean.
>
> That way, you could write code like this:
>
> if ( <int>$_GET['id'] ) {
>     $user =3D getUser($_GET['id']):
> }
> else {
>     echo "Invalid ID provided";
> }
>
> Which would be equivalent (given a type hint on getUser() and no
> strict_types declaration) to this, but without needing to use exceptions
> as flow control:
>
> try {
>     getUser($_GET['id']);
> }
> catch ( TypeError $e ) {
>     echo "Invalid ID provided";
> }
>
>
> Regards,
>
> --
> Rowan Tommins (n=C3=A9 Collins)
> [IMSoP]
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--0000000000004169ff0595591abc--