Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:109604
MIME-Version: 1.0
References: <CAPyj-LDfdATXFD+dc5AY9EqWWxgf8LP1joD2fzvm==1gUoN35A@mail.gmail.com>
 <C3F55856-66AF-44F5-8F43-8E41FA8DC6E8@gmail.com> <CAPyj-LBt_Cq+qa49+H3Tav+uepSJ23+TPg_JN5DofGC7y8fnoQ@mail.gmail.com>
 <6aebe21d-2137-885e-5ee9-99d4f917a7f9@gmail.com> <CAPyj-LAo0tnG=tMJ_ir9SoaYKa1WM1AYCAiyfQ8Xkkx=W4usEw@mail.gmail.com>
 <5071DCCE-4572-4B1F-A50B-832C5EA74795@gmail.com>
In-Reply-To: <5071DCCE-4572-4B1F-A50B-832C5EA74795@gmail.com>
Date: Mon, 13 Apr 2020 13:28:41 +0200
Message-ID: <CAPyj-LD87_6VcUNLtJbqQatUpBO1fTDb1f_ZgLyAp2fSjqYaLA@mail.gmail.com>
To: Rowan Tommins <rowan.collins@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [PHP-DEV] [DISCUSSION] Match expression
From: tovilo.ilija@gmail.com (Ilija Tovilo)

> Firstly, block expressions are a foundational part of the Rust
> language, not a special case used in only one place.

From a previous e-mail:

> It would be possible for the blocks to return values (though not with
> the return keyword). I've created a small prototype a few weeks ago:
>
> https://github.com/php/php-src/compare/master...iluuu1994:block-expression
> Heavily inspired by Rust:
> https://doc.rust-lang.org/reference/expressions/block-expr.html
>
> While this would perfectly solve the problem perfectly it feels a
> little foreign in PHP. Either way, this is something that can be
> discussed an implemented in a separate RFC.

We can't do everything at once. The current block syntax is completely
compatible with that suggestion. All we'd have to do is relax the
restriction of only allowing blocks when the result isn't used.

> it makes *all* the control flow blocks in Rust feel more natural to
> developers coming from other languages.

Same thing here. If you don't use the result value, it looks just like
the switch. That's why I'd feel odd to require a semicolon.

> the page you linked calls out an ambiguity caused by omitting the
> semicolon

This code is parsed like this:

```
match($x) { 1 => ['foo', 'bar'] }
[0];
```

* statement list
    * match expr
    * array literal

Note that we can't have ambiguous grammar since Bison would
immediately expose it.

> It then explains the important restriction of only omitting the
> semicolon if the result is void/null rather than a concrete value.

That's true. Unfortunately we don't have this info at compile time.
That's why we throw away the expression result just like with any
other expression statement.

> I would probably vote no to the current proposal

I understand. Everybody is entitled to their opinion. If the vote
fails that doesn't mean we'll just completely give up. I would
reiterate and try again. Sadly, it's very hard to get a feel for how
many people have which opinion through the mailing list.

Ilija