'switch-expression' and the 'type guard' unary operator demo

Hi Mike

Is there a strong reason to change to using fat arrows and colons?

The reason is statement/expression semantic.

The reason for choosing comma over semicolon is because in PHP semicolons
are used only as statement separator while commas are used as expression
separator within brackets and item separator of some statements that can
take numbers of item such as echo or variable/property declarations.
Since switch-expression is a list of expression pairs, commas should be
used to separate its items.

And the reason for choosing fat arrow over colon is still the same as
above, expression semantic. In PHP fat arrows (double arrows) were used
only to separate key and value until 7.4 where their role has extended
(arrow functions), while colons are used in three places labels, ternary
operator and return types. Since cases in switch statements are labels,
colons are approprate. But as I stated above, switch-expression is a list
of expression pairs so it should use syntax like array rather than its
statement counterpart. If PHP was using colon as key/value separator then
colons should be used here.

And here are examples of languages that use arrow-like syntax:

[C#]

var result = bank.Status switch
{
BankBranchStatus.Open => true,
BankBranchStatus.Closed => false,
BankBranchStatus.VIPCustomersOnly => isVip
};

[Rust]

let message = match x {
0 | 1 => "not many",
2 ..= 9 => "a few",
_ => "lots"
};

[Kotlin]

var result = when (number) {
0 -> "Invalid number"
1, 2 -> "Number too low"
3 -> "Number correct"
4 -> "Number too high, but acceptable"
else -> "Number too high"
}

What about break?

Let's see this example.

for ($i = 0; $i < 100; $i++) {
$x = getX($i);
doSomething(
$i,
$x,
switch ($x) {
case 0 => 'ZERO',
case 1 => 'ONE',
case 2 => 'TWO',
case 3 => 'THREE',
default => break,
},
);
}

This shoud break switch or for? And if it breaks switch NULL should
be returned but this will be the same as omitting default. And if it
breaks for, call to doSomething() will be incomplete because a call
frame was already pushed to VM stack. As I know ongoing function calls can
only be aborted by exceptions (and return should not be allowed either, I
need to fix that) so expressions must give something or throw.

Cheers

On Oct 19, 2019, at 12:40 PM, Kosit Supanyo webdevxp.com@gmail.com
wrote:

Hi Internals

I've just finished an implementation of 'switch-expression' that have been
discussed recently. So I would like to present my ideas here.

This is great to see that you proactively implemented this.

The basic syntax of switch-expression in this implementation is:

$result = switch ($expr) {
case $cond1 => $result1,
case $cond2 => $result2,
case $cond3 => $result3,
default => $default_result,
};

However, why the need to deviate with the existing syntax, making
refactoring between switch statements and switch expressions more work that
it needs to be. Is there some reason why keeping colons and semlicolons
would not work?

Given your syntax manually refactoring existing switches to use
expressions, or refactoring back from expressions to statements will
require more and tedious keystrokes than if you just kept colons and
semicolons. Is there a strong reason to change to using fat arrows and
colons?

You can omit parenthesized expression which is shortcut to switch (true).
This change applies to switch statement as well.

$v = switch {
case $x >= 0 && $x <= 100 => 1,
case $x >= 100 && $x <= 200 => 2,
default => 3,
};

switch {
case $x >= 0 && $x <= 100:
doSomething1();
break;
case $x >= 100 && $x <= 200:
doSomething2();
break;
default:
doNothing();
break;
}

I do very much like this innovation.

Would love to see this work for switch statements too.

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 = 'd';
$v = switch ($x) {
case 'a' => 1,
case 'b' => 2,
case 'c' => return true,
default => throw new Exception("'$x' is not supported"),
};

What about break?

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 = 'This is a string';
$v = <int>$a; // TypeError: Value is expected to be int, string given

Just like type hints, can accept nullable types.

$v = <?int>switch ($x) {
case 'a' => $result1,
case 'b' => $result2,
};

Nice!

-Mike

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 => print "ONE\n",
case 2 => print "TWO\n",
};

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.
https://github.com/webdevxp/php-src/blob/switch-expression/Zend/zend_language_scanner.l#L1460
https://github.com/webdevxp/php-src/blob/switch-expression/Zend/zend_language_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_language_parser.y#L443

https://github.com/webdevxp/php-src/blob/switch-expression/Zend/zend_language_parser.y#L1107

• 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.

$v = switch ($x) {
case < <int>$y => 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.

Like function declaration and function expression in JavaScript, if
switch appears as first token at statement level it will be recognized
as
statement but if switch is in expression context it will be
switch-expression.

switch ($expr) {
case $cond1 => $result1,
case $cond2 => $result2,
case $cond3 => $result3,
default => $default_result,
};
// Parse error: syntax error, unexpected '=>' (T_DOUBLE_ARROW)

But this is OK.

!switch ($expr) {
case $cond1 => $result1,
case $cond2 => $result2,
case $cond3 => $result3,
default => $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 = switch {
case $x >= 0 && $x <= 100 => 1,
case $x >= 100 && $x <= 200 => 2,
default => 3,
};

switch {
case $x >= 0 && $x <= 100:
doSomething1();
break;
case $x >= 100 && $x <= 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 => foo(), case >100 => bar(), default
  => baz() }
• Different values compared against the same expression using the same
  operator, e.g. match( $exception instanceOf ) { case FooException =>
  handleFoo(), case BarException => 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 = 'd';
$v = switch ($x) {
case 'a' => 1,
case 'b' => 2,
case 'c' => return true,
default => 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 = 'This is a string';
$v = <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 = 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é Collins)
[IMSoP]

Like function declaration and function expression in JavaScript, if
switch appears as first token at statement level it will be recognized as
statement but if switch is in expression context it will be
switch-expression.

switch ($expr) {
case $cond1 => $result1,
case $cond2 => $result2,
case $cond3 => $result3,
default => $default_result,
};
// Parse error: syntax error, unexpected '=>' (T_DOUBLE_ARROW)

But this is OK.

!switch ($expr) {
case $cond1 => $result1,
case $cond2 => $result2,
case $cond3 => $result3,
default => $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?

What restriction are you referring to? The forced default or the semi-colon being required?

If default, I concur.

I've always felt switch(true) was rather limited in its advantage over if-elseif.

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.

With that, I would even argue that we deprecate else. Except I know that would be a battle so I wouldn't actually suggest it. :-)

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 => foo(), case >100 => bar(), default => baz() }
• Different values compared against the same expression using the same operator, e.g. match( $exception instanceOf ) { case FooException => handleFoo(), case BarException => handleBar() }

However, I would very much like to see both of those options, for switch expressions and switch statements.

It is "syntax sugar," but IMO[1] programming languages evolve best when they recognize commonly used-patterns and then apply syntax sugar to make those patterns more obvious, less error prone and easier to reason about.

Further, your introduction of a match keyword here is intriguing, and we could probably leverage it for other use cases. Maybe as an alternate to switch statements that do not require breaks?

$x = 'd';
$v = switch ($x) {
case 'a' => 1,
case 'b' => 2,
case 'c' => return true,
default => throw new Exception("'$x' is not supported"),
};

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.

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 = 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";
}

+1 to use for can-cast checking. In GoLang this is called a type assertion and is thus similar:

if id,ok = get['id'].(string); ok {
$user = get['id'].(string);
} else {
echo "Invalid ID provided";
}

It would be super nice for PHP to have an equivalent.

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):
}

-Mike
[1] https://mikeschinkel.me/2019/in-defense-of-syntactic-sugar/ <https://mikeschinkel.me/2019/in-defense-of-syntactic-sugar/