[RFC][DISCUSSION] switch expression

Hi Dan

First of all, thank you for your feedback. I appreciate your time.

I think it's worth noting that the switch expression solves the
problems it does implicitly, not directly.

1. Returning values: Of course, this is the main argument for the
   switch expression (regardless of the other issues present in the
   statement version).
2. Fallthrough: A fallthrough for the expression version doesn't make
   sense because the point of every case is to return some value. A
   fallthrough would cause the value to be discarded, returning the value
   from the next case that breaks. Furthermore since every case only
   accepts a single value there's not even a way to express a break right
   now (as it is a statement).
3. Inexhaustiveness: The switch expression has to evaluate to
   something. When no case is executed we can either make it return null
   or throw an exception. Since it is better to be explicit I chose the
   latter.

The only issue that doesn't have any direct justification for being
different from the statement is the type coercion which is why I
decided against changing it. It's a one line fix so believe me that I
was tempted. But I think it's important to keep them consistent.

1. The behaviour of switch with regards to type conversion is the
   biggest thing I care about. If the RFC isn't going to touch that, then
   it's way less interesting to me.

I understand. As you mentioned I'm trying not to make the distinction
between the statement and expression arbitrary.

2. In general, I think that using the switch keyword with slightly
   different behaviour is not a good idea. Even if we had 'editions' in
   PHP, having subtly different behaviour is very confusing. A better
   approach would be to use a new keyword (maybe 'select') that has the
   correct behaviour from the start.

I used the switch keyword for the simple reason that it very much
still is a switch. It uses the same AST, same code generation, same
opcodes.

3. Fallthrough:

"The fallthrough behavior can't reasonably be changed in the switch
statement because it would break a lot of code. However this RFC
porposes allowing multiple conditions per case so that the intention
of running the same code can be expressed more clearly. "

I don't think this is the right approach. Most new languages have the rules of:

• each 'case' statement has an implicit break statement at the end of that case.
• they provide an explicit 'fallthrough' keyword for where fall
  through is desired.

This sound like an extension of the approach described in the RFC.
There's nothing stopping us from allowing a fallthrough keyword,
although I personally don't see a huge need for it. Either way, the
fallthrough keyword still wouldn't make sense in the switch
expression.

• btw it might be worth thinking about pattern matching as well.

I've mentioned pattern matching briefly in my original email. There
are a few use cases in PHP right now, namely array destructuring,
class destructuring (public properties) and ranges. Most PHP libraries
make extensive use of accessors so at the moment I don't think the
complexity of the feature justifies the limited use cases. This may
very well change in the future (for example if PHP ever gets C# style
get/set accessors).

Currently the below is supported, but is also horrific coding (imo)

After this RFC your function could be rewritten like this:

function checkValue(int $x, bool $errorIfOverTen) {
    return true switch {
        $x < 5 => "too small\n",
        $x > 10 && $errorIfOverTen => "value is over ten, which is not
allowed.\n",
        default => "Ok\n",
    };
}

which doesn't look too bad IMO. It has been suggested to make the true
optional in this case. I still haven't fully formed an opinion on
that. It would make the syntax ambiguous again for sure.

I hope that clears up some of the points you've mentioned.

Ilija

Hi Arnold

However, operations don't ever throw exceptions, but throw an error instead.

I replaced it with a new, more fitting UnhandledSwitchCaseError.

Thanks!
Ilija