[RFC] Short-match

Another situation in which _ might be useful. match (_) { ... }

Hey Doug,

Hi Marco,

Is there any chance you can elaborate on why you feel it's a bad idea?

Both you and Sara at different points have talked about thinking was bad
practice, but I've not read anything compelling about why it should be
considered as such.

Kind regards,
Doug Nelson

Hey Larry,

On Mon, Dec 14, 2020 at 6:34 PM Larry Garfield larry@garfieldtech.com
wrote:

I present to Internals this tiny RFC to follow up on the match()
expression RFC from earlier in the year. There was solidly positive
support for this shortcut previously but it was removed for simplicity
at
the time, with the intent to bring it back later. It's now later.

https://wiki.php.net/rfc/short-match

Overall back to the switch (true) case, which IMO is not a good idea
in
first place :|

Nothing wrong with using a set of conditional that are put in a sequence
through if (), for these rare cases.

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

--
Doug Nelson
Senior Software Engineer

It's effectively yet another way to write something that already exists,
which means more syntax to learn, more syntax to deal with (in downstream
tooling), and that for an edge case being a fall-through list of boolean
expressions, which is what already happens by using if with early return
statements.

Let me rephrase it then:

• It brings little to no advantage to the table for something seen very
  rarely (match already being super-rare, since adoption didn't even start
  yet)
• It increases language complexity

Every time new AST is to be added, that complexity needs to be weighed
against the benefits, and I don't see any compelling ones here.

I don't understand what's the advantage of the short match? Why would
I ever want to use it?
If I ever saw this kind of code in my codebase then I would
immediately refactor it to use if statements. That is just abuse of
match statement in my opinion. If someone wants to abuse match syntax
like this then I think they should put (true) after it to make it
clear what they are doing.
Allowing match without the match subject will be lead to confusing
problems for a lot of beginners who will forget the match subject or
mis-copy it and then wonder why their application does not behave as
it should.
IMHO I see no benefit of adding this feature to PHP, and I actually
see disadvantages.

Both you and Sara at different points have talked about thinking was bad
practice, but I've not read anything compelling about why it should be
considered as such.

I'm not a full -1 on the concept (especially as match(true) has the
convenience of returning a value), but it's very square peg in a round hole
to me.

At the end of the day though, that's a style choice and not one I have any
business imposing on anyone, and certainly within the context of this diff,
the actual change is trivial. It's sugar for match(true) that looks like
match. /shrug

I might suggest broadening the scope to include switch as well though.
If we're going to codify match(true) as a pattern, we should at least be
consistent about it.

-Sara

Den 2020-12-14 kl. 22:23, skrev Sara Golemon:

Both you and Sara at different points have talked about thinking was bad
practice, but I've not read anything compelling about why it should be
considered as such.

I'm not a full -1 on the concept (especially as match(true) has the
convenience of returning a value), but it's very square peg in a round hole
to me.

At the end of the day though, that's a style choice and not one I have any
business imposing on anyone, and certainly within the context of this diff,
the actual change is trivial. It's sugar for match(true) that looks like
match. /shrug

I might suggest broadening the scope to include switch as well though.
If we're going to codify match(true) as a pattern, we should at least be
consistent about it.

-Sara

I think it's a good point to keep it consistent with switch,
i.e. if moving forward make the same change in switch. Then
when mixing and matching on at least don't need to remember
where true is needed...

r//Björn L

Both you and Sara at different points have talked about thinking was bad
practice, but I've not read anything compelling about why it should be
considered as such.

I'm not a full -1 on the concept (especially as match(true) has the
convenience of returning a value), but it's very square peg in a round hole
to me.

At the end of the day though, that's a style choice and not one I have any
business imposing on anyone, and certainly within the context of this diff,
the actual change is trivial. It's sugar for match(true) that looks like
match. /shrug

I might suggest broadening the scope to include switch as well though.
If we're going to codify match(true) as a pattern, we should at least be
consistent about it.

-Sara

I lean more on the side of +1 but otherwise agree with Sara here. I'm
apathetic on including switch but it's worth considering.

If this (slightly) better aligns someone's code with how they're
thinking about the problem then yay.

Le 17 déc. 2020 à 17:23, Sara Golemon pollita@php.net a écrit :

match is an expression, where as if-else construction is not. This
allows for combining it with a potential future feature of single line
functions and methods. For example (hypothetical syntax is used):

$getNumber = fn(int $number) => match {
   $number < 0 => NumberKind::NEGATIVE,
   $number == 0 => NumberKind::ZERO,
   $number > 0 => NumberKind::POSITIVE,
};

That does read attractively, yes. This is the example that should have
been offered first as it shows the expression nature shining.

To contrast that with what would be possible now in an expressive
functional form:

$getNumber = fn(int $number) => [
-1 => NumberKind::NEGATIVE,
0 => NumberKind::ZERO,
1 => NumberKind::POSITIVE,
][$number <=> 0];

The match form certainly reads more naturally than the spaceship indexing
form even though both take up equal space.

-Sara

If you mean a version of if that works in expressions, there already exists a standard operator for that. Once its historical associativity goof is definitely fixed, you will be able to write:

$getNumberKind = fn(int $number) =>
       $number > 0 ? NumberKind::POSITIVE :
       $number == 0 ? NumberKind::ZERO :
       $number < 0 ? NumberKind::NEGATIVE :
       throw new \TypeError;

There is a semantic advantage of match over ? : , though, namely its exhaustivity: You don’t need to add a “panic” default case in order to catch logic errors.

—Claude

match is an expression, where as if-else construction is not. This
allows for combining it with a potential future feature of single line
functions and methods. For example (hypothetical syntax is used):

$getNumber = fn(int $number) => match {
    $number < 0 => NumberKind::NEGATIVE,
    $number == 0 => NumberKind::ZERO,
    $number > 0 => NumberKind::POSITIVE,
};

That does read attractively, yes. This is the example that should have
been offered first as it shows the expression nature shining.

To contrast that with what would be possible now in an expressive
functional form:

$getNumber = fn(int $number) => [
-1 => NumberKind::NEGATIVE,
0 => NumberKind::ZERO,
1 => NumberKind::POSITIVE,
][$number <=> 0];

The match form certainly reads more naturally than the spaceship indexing
form even though both take up equal space.

-Sara

It looks like the quoted part from someniatko changed from a named function to an anon function? Not sure what happened there.

I've included both a named and lambda version of his example in the RFC, however, and linked to the short-functions RFC as that would allow the form he originally listed. They complement each other nicely.

--Larry Garfield

$this->handler = match {

      null === $var => 'null',
      true === $var => 'true',
      false === $var => 'false',
      is_string($var) => '"'.$var.'"',
      is_callable($var) => 'callable',
      is_object($var) => get_class($var),
      default => rtrim(print_r($var, true)),

};

I saw a proposal connected to match about a year ago that included type
based matching, something like:

match ($var) {
true => 'true',
false => 'false',
instanceof int => "int($var)",
instanceof string => ""$var"",
instanceof object => get_class($var),
instanceof DateTimeInterface => $var->getTimestamp(),
default => rtrim(print_r($var, true)),
};

That might satisfy at least one of the use cases in a general way.

I do like Nikitas idea to make it a TypeError for non-bool matches.

Yeah. Within the context of this featurette, that's something we should
include in the proposal. If you're doing a match(true/false/other-literal)
(explicitly or implicitly) then your cases should be commensurately more
well constrainted.

-Sara

If we allow "switch {...}" to represent "switch (true){...}" then the value switch compares will be hidden and less obvious to a developer if they are forgetting to consider switch's evaluation behavior. For some people this would increase the WTF factor.

How does "switch (true){...}" cause less surprise than "switch {...}” for loose comparisons? IMO, seeing the boolean value true causes more confusion, since it matches any truthy value but the constant value in the expression is a bool.

Cheers,
Ben