Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:109607
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> <CAPyj-LD87_6VcUNLtJbqQatUpBO1fTDb1f_ZgLyAp2fSjqYaLA@mail.gmail.com>
 <e801f32f-7f74-4d3e-4494-5242f213f101@gmail.com>
In-Reply-To: <e801f32f-7f74-4d3e-4494-5242f213f101@gmail.com>
Date: Mon, 13 Apr 2020 12:08:57 -0300
Message-ID: <CAEsg9X1=u+ATO8h4nSxOyBstOgBwS1Lhv2bEC+pHv8gbD21A1w@mail.gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000005b02205a32d7746"
Subject: Re: [PHP-DEV] [DISCUSSION] Match expression
From: david.proweb@gmail.com (David Rodrigues)

--00000000000005b02205a32d7746
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

With all the humility of the world and without wanting to be exhaustive
about this, my only question is why can't we keep it as a switch, instead
of creating a new keyword?

$x =3D switch ($y) {
    case 0: return 1;
    case 1: return 20;
    // default: return null;
};

I say this because, in the future, we could do something similar for if():

$x =3D if ($y instanceof Foo) {
    return $y->bar();
} else if ($y instanceof Bar) {
    return $y->foo();
}; // else { return null; }

Or even for loopings:

$x =3D foreach ($items as $item) {
    yield $item;
}; // $x =3D=3D $items

So we would not need to create a new keyword for each equivalent type when
used as an expression.

The only reason would be something like "switch has no return support", but
this could happen exclusively in this scope, just as "use ()" exists only
in functions and not in methods, which are basically the same thing,
however, in different scopes. Likewise, "break 2" would be impossible in
this case, so just issue an error saying "break n is not supported in this
situation".


Atenciosamente,
David Rodrigues


Em seg., 13 de abr. de 2020 =C3=A0s 11:49, Rowan Tommins <rowan.collins@gma=
il.com>
escreveu:

> On 13/04/2020 12:28, Ilija Tovilo wrote:
> >> It would be possible for the blocks to return values (though not with
> >> the return keyword).
> >> [...]
> > We can't do everything at once.
>
>
> Then why not introduce the match expression first, and add block
> expressions (as a general concept) later? That way, we don't need all
> the special restrictions on when to use them, and can work out a
> consistent set of rules for them which can apply language-wide, rather
> than being constrained later by decisions we make half-implementing them
> now.
>
> The ability to use them with short closure syntax would be very
> interesting, if the scoping/capture rules could be agreed.
>
>
> >> 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.
>
>
> Not really. In Rust, it's about making a whole bunch of control
> structures, which are already consistent with each other, more user
> friendly (but still consistent). In your proposal, it's about making one
> specific control structure look slightly more like other syntaxes in the
> same language, by adding a special case which applies nowhere else.
>
> To be specific, in PHP, there is no "omitted semicolon" at the end of
> "if ($x) { y(); }" - that is just how the syntax is defined. There's no
> need to have a parser rule to allow it to look like C or Java, because
> it already does.
>
>
> > This code is parsed like this:
> >
> > ```
> > match($x) { 1 =3D> ['foo', 'bar'] }
> > [0];
> > ```
> >
> > * statement list
> >      * match expr
> >      * array literal
> >
> > Note that we can't have ambiguous grammar since Bison would
> > immediately expose it.
>
>
> I'm not sure what you mean by "we can't have ambiguous grammar" - the
> code above *is* ambiguous, in that it could be defined to mean one of
> two things; what you've shown is which definition your implementation
> defines.
>
> That resolution makes sense for that example, but consider some others:
>
> // As proposed, parsed as two meaningless expression-statements; as a
> normal expression, would select and then invoke a callable
> match($x) { 1 =3D> 'print', 2 =3D> 'var_dump' }
> ($x);
>
> // Invalid under the proposed rule, but a valid method call if match was
> always a normal expression
> match($x) { 1 =3D> new Foo, 2 =3D> new Bar }
> ->doSomething();
>
>
> To be fair, the same limitation exists for closures, where this is invali=
d:
>
> function($x) { echo $x; } ("Hello");
>
> and you have to write this instead:
>
> (function($x) { echo $x; }) ("Hello");
>
>
> So I guess the above would follow the same rule to force expression
> context:
>
> (match($x) { 1 =3D> 'print', 2 =3D> 'var_dump' })($x);
>
> (match($x) { 1 =3D> new Foo, 2 =3D> new Bar })->doSomething();
>
> The only downside is that omitting the parentheses wouldn't be an error,
> as with the closure case, it would just silently do nothing, which might
> be rather confusing. Dropping the special semicolon handling would mean
> it either did the expected thing or gave a parse error straight away.
>
>
> Regards,
>
> --
> Rowan Tommins (n=C3=A9 Collins)
> [IMSoP]
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--00000000000005b02205a32d7746--