Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:121030
MIME-Version: 1.0
References: <CAPyj-LB16MUDNkgdQ7TrHpgNG2gD86H7+OP_g_rbuH0KYR9ZzQ@mail.gmail.com>
In-Reply-To: <CAPyj-LB16MUDNkgdQ7TrHpgNG2gD86H7+OP_g_rbuH0KYR9ZzQ@mail.gmail.com>
Date: Sun, 10 Sep 2023 11:35:44 -0300
Message-ID: <CADK1yXKALob62e7QA2AyxDmX6xFk3tLkUgy2-e55nVEeKK=6xw@mail.gmail.com>
To: Ilija Tovilo <tovilo.ilija@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000001d8ef20605022291"
Subject: Re: [PHP-DEV] [RFC][Draft] Match block
From: deleugyn@gmail.com (Deleu)

--0000000000001d8ef20605022291
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, Sep 8, 2023 at 7:16=E2=80=AFPM Ilija Tovilo <tovilo.ilija@gmail.com=
> 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
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>
Hi Ilija,

This seems like an interesting subject for the PHP language, but
unfortunately doesn't take the direction I would much have preferred. The
use of `<-` to denote a different style of return statement in a block
feels quite "alien" (for lack of a better word) in the language for me. In
addition to that, I'm also not sure if there's anything else in PHP that
behaves differently when a return value is expected or not - this is in
relation to the difference between `$result =3D match()` vs `match()` witho=
ut
expecting a result. If there's anything else in PHP that already has a
similar behavior, it might be worth adding it to the RFC so that we can
relate the subjects.

To me it would be much better to stick with the existing language
constructs just as-is.

```
<?php

var_dump(match ('foo') {
    'foo' =3D> {
        echo "foo branch reached\n";
    },
});
// foo branch reached
// NULL

var_dump(match ('foo') {
    'foo' =3D> {
        echo "foo branch reached\n";

        return 'this will be dumped';
    },
});
// foo branch reached
// string(19) "this will be dumped

var_dump(fn () =3D> {
    echo "auto-capturing short closure invoked\n";
}());
// auto-capturing short closure invoked
// NULL

var_dump(fn () =3D> {
    return 'foo';
}());
// string(3) "foo"

$foo ??=3D {
    bar();
};
var_dump($foo);
// NULL

$foo ??=3D {
    bar();

    return 'baz';
};
var_dump($foo);
// string(3) "baz"
```

There's a somewhat related discussion on this RFC
https://wiki.php.net/rfc/auto-capture-closure#multi-line_expressions which
comes to mind and was just 2 votes short of have been approved.
Other good-related RFCs are https://wiki.php.net/rfc/short-match and
https://wiki.php.net/rfc/short-functions which creates a really nice
symmetry in the language syntax.

Ultimately, this is a sad 10-year-long discussion (as summarised here:
https://externals.io/message/113740#113833) that seems impossible to move
forward within the PHP language. The door of creating of a block with
auto-capture look-and-feel much better across many different aspects of the
language, but it's always shutdown by enough long-time voters.

Overall, between the choice of creating a new syntax that "kind of
represents return statements on specific scenarios" or option 3 - do
nothing, I would prefer to do nothing until we manage to gather enough
voters to overcome the "no-auto-capture" camp.

--=20
Marco Deleu

--0000000000001d8ef20605022291--