Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:121048
Feedback-ID: i8414410d:Fastmail
User-Agent: Cyrus-JMAP/3.9.0-alpha0-745-g95dd7bea33-fm-20230905.001-g95dd7bea
Mime-Version: 1.0
Message-ID: <4965ef59-1937-44aa-a3ec-f67664420300@app.fastmail.com>
In-Reply-To: 
 <CAPyj-LB16MUDNkgdQ7TrHpgNG2gD86H7+OP_g_rbuH0KYR9ZzQ@mail.gmail.com>
References: 
 <CAPyj-LB16MUDNkgdQ7TrHpgNG2gD86H7+OP_g_rbuH0KYR9ZzQ@mail.gmail.com>
Date: Tue, 12 Sep 2023 18:16:16 +0000
To: "php internals" <internals@lists.php.net>
Content-Type: text/plain
Subject: Re: [PHP-DEV] [RFC][Draft] Match block
From: larry@garfieldtech.com ("Larry Garfield")

On Fri, Sep 8, 2023, at 10:16 PM, Ilija Tovilo wrote:
> Hello everyone
>
> I've been working on match blocks over the last few weeks.
> https://wiki.php.net/rfc/match_blocks
>
> I've already shared it in R11 and got conflicting feedback, which
> makes me unsure on how to proceed. We have a few options.
>
> 1. Add blocks only to match, possibly adding blocks to other
> constructs in separate RFCs (the approach of this RFC)
> 2. Support block expressions as a language-level concept, analogous to
> https://doc.rust-lang.org/reference/expressions/block-expr.html
> 3. Do nothing
>
> The two main complaints/questions I've gotten was whether this
> approach is the right one, and whether the syntax can be improved. The
> RFC tries to go into detail on explaining the rationale for the chosen
> approach. Additionally, it proposes a few alternate syntax options,
> although none of them are very satisfactory.
>
> At this point I'm unsure whether a proposal can satisfy all camps. Let
> me know if you have any thoughts/ideas.
>
> Ilija

As we've discussed elsewhere, I favor option 2: Language level concept.  I cannot speak to the implementation details, but let me offer two specific bits of justification.

1. The RFC says "For match, whether the block should require returning a value depends on whether the match itself returns a value." - I disagree.  Returning a value should always be legal; if the value isn't assigned to a variable it is lost, but oh well, that's how PHP already works.  Moreover, if the argument is rather "if match's result is saved, then each branch *must* return a value", well, the same is true for use in many other cases, such as with the null short-hands.

2. Speaking of, this is a pattern I find myself writing all the time:

class Foo {
  private array $things;

  public function getThing(string $id): ?Thing {
    $this->things ??= $this->makeThingTable();
    return $this->things[$id] ?? null;
  }

  private function makeThingTable(): array {
    // Something complex here.
  }
}

Allowing multi-line expressions on ??= would allow that to be collapsed to a single function, without the need to come up with a name for makeThingTable(), or splitting logic between two methods, etc.  I believe that is a valid and useful use case for multi-line expressions outside of match() that can/should be supported.  (One could argue that it's possible to just use a self-executing closure, which is true, but is also verbose and ugly and requires manual capture.  That same option is also available for match arms today, with the same problem, which is why we're looking for a better solution.)

class Foo {
  private array $things;

  public function getThing(string $id): ?Thing {
    $this->things ??= {
      // Something complex here.
    };
    return $this->things[$id] ?? null;
  }
}


I am flexible on the syntax used.  I agree that a keyword would be more PHP-ish than <-, but I wouldn't start a riot either way.  If just { } makes the parsing hard, I have in the past suggested {{ }} to denote a multi-line expression, which should be sufficiently parser-unique.

> We could settle for a solution that works for all cases, returning null by default. Whether this solution is acceptable is likely a matter of taste. 

That would taste just fine to me, frankly, and I'm OK with the code block shown right after it.

--Larry Garfield