Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:107597
MIME-Version: 1.0
References: <CAP=w73VJ6pxstVzyfFkOp=esX7ne-LosWP1Eb8Ac0u-JeROPRA@mail.gmail.com>
 <bd36083e-a84d-69e1-725c-7b026a009be1@gmail.com> <91095002-BA0D-440B-8FAB-AA003A0EDB69@newclarity.net>
In-Reply-To: <91095002-BA0D-440B-8FAB-AA003A0EDB69@newclarity.net>
Date: Mon, 21 Oct 2019 09:51:10 +0100
Message-ID: <CALKiJKp64cBUDSOdaz9sJ3SxjoeJO26vH6iVF0tMrBwLK8=j0w@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000b19dc4059567c948"
Subject: Re: [PHP-DEV] 'switch-expression' and the 'type guard' unary operator demo
From: rowan.collins@gmail.com (Rowan Tommins)

--000000000000b19dc4059567c948
Content-Type: text/plain; charset="UTF-8"

On Sun, 20 Oct 2019 at 22:35, Mike Schinkel <mike@newclarity.net> wrote:

> What restriction are you referring to?  The forced `default` or the
> semi-colon being required?
>
>

Neither; I was referring to not being able to put a switch expression as a
statement on its own, which Kosit has explained is a limitation of the
parser.



> I would much prefer to use a switch for multiple, mutually exclusive cases
> no matter what how complex the expression is because with a switch the
> cases expressions line up vertically. With `if` and `else if` it is harder
> to vertically eyeball the different mutually exclusive cases.
>


I've never particularly been bothered by it, but wouldn't adding four
spaces in your "if" statement make it line up with all your "elseif"
statements?



> 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?
>
>
> It should have its prior value, since the expression did not complete.
>
> Alternately we could choose to always assign it null on return or break.
>
> But how often will we have this use-case?  Only for global variables,
> which hopefully will eventually become extinct in userland code.
>
>


Not just global variables, no; it could be assigning an object property
($this->foo = switch($x){ case 1 => return 1; }) for instance. It could
also be in the argument for a function call ( doSomething(switch($x){ case
1 => return 1; }) ) in which case presumably the function would not be
called at all? Overall, having a "return" in the middle of an expression
would be very confusing, I think.





> That said, we should almost be able to do *both*, and just let PHP throw
> an error if there is a problem. This would be useful if you know 100% that
> the code won't fail because of the code that came before it:
>
> if ( is_numeric($_GET['id'] ?? 0 ) ) {
>     $id = intvar($_GET['id'] ?? 0);
>
>      $user = getUser(<int>$id):
>
> }
>
>

I'm not sure what the point of this example is. You've just cast to int, so
the assertion can never fail, and if getUser has a type hint, it's about to
make that assertion anyway.

Regards,
-- 
Rowan Tommins
[IMSoP]

--000000000000b19dc4059567c948--