Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:107595
MIME-Version: 1.0
References: <CAP=w73VJ6pxstVzyfFkOp=esX7ne-LosWP1Eb8Ac0u-JeROPRA@mail.gmail.com>
 <C86ED976-5E52-428E-A824-0429601AB3FE@newclarity.net> <CAP=w73VNggn6yXnueYwfUS0EbCB6eFMGTy72DRiiTTEWdOVhMQ@mail.gmail.com>
 <3D85D31D-5DDD-42AA-B465-6ADBE72D952A@newclarity.net>
In-Reply-To: <3D85D31D-5DDD-42AA-B465-6ADBE72D952A@newclarity.net>
Date: Mon, 21 Oct 2019 06:08:59 +0700
Message-ID: <CAP=w73U-KF2WF6oaev2tKy6oP+2xJ+JQox8zHdLOeZufj9ZVeQ@mail.gmail.com>
To: Mike Schinkel <mike@newclarity.net>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000902ae005955fa72c"
Subject: Re: [PHP-DEV] 'switch-expression' and the 'type guard' unary operator demo
From: webdevxp.com@gmail.com (Kosit Supanyo)

--000000000000902ae005955fa72c
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Mike

In a brace-enclosed block statements are separated by semi-colons, not
> commas.


Yes because they are statements, that's the point which I've stated many
times. And if your argument is that there's no place in PHP that uses
commas within curly braces, you're wrong. PHP already has one.

use X\Y\Z\{
    A,
    B,
    C,
};

The reason to choose what to be a separator is not about the container but
rather its items and semantics associated with them. And there's many
languages out there using commas to separate expressions within curly
braces if you did do some researches you might not think they are
inconsistent at all. In fact I'd already gave you some examples in previous
reply (C#, Rust).

We can either limit a brace-enclosed expression to containing only simple
> expressions =E2=80=94 which as I said seems too limiting =E2=80=94 or we =
can enable the
> future *potential *for multi-line statements in a block-enclosed
> expression.


No one is limiting anything. I'm working on block expressions too. One of
them is `eval` block which would be like:

$z =3D eval {
    $x =3D doSomething1();
    $y =3D doSomething2();
    if ($x >=3D 0 && $y >=3D 0) {
        give $x + $y;
    }
    give null; // can be omitted
};

If you think that anything inside curly braces must be separated by
semicolon, you are the one that limit yourself.

As I envision, it should break `for`.  And since the fact the call frame is
> already pushed does not stop a `throw` from working I do not see why it
> should stop a `break` from working.
>

That's because `throw` do different thing at the engine level not just
jumping things like `break`, `continue` or `goto`.

BTW, when I code I use `break` wherever possible instead of `throw`[1-6],
> and only ever use `throw` and `try...catch` when I am forced to. So
> supporting throw but not  break here would require an additional comparis=
on
> after the `switch` expression for people who like me avoid `throw`, which
> is not ideal.


If `break` is allowed in switch-expressions and its behavior is to break
outer loop, don't you think it could be an another inconsistency or
confusion? Because I'm 100% sure when people see `break` within `switch`
they'll all think it should break `switch` not something else.

Regards

On Mon, Oct 21, 2019 at 4:12 AM Mike Schinkel <mike@newclarity.net> wrote:

> Hi Kosit,
>
> Thank you for your reply.
>
> On Oct 20, 2019, at 3:54 AM, Kosit Supanyo <webdevxp.com@gmail.com> wrote=
:
>
> Hi Mike
>
> Is there a strong reason to change to using fat arrows and colons?
>
> The reason is statement/expression semantic.
>
>
> Okay, so you chose commas and fat arrows because of perceived consistency=
.
> I can buy that.
>
> However, I think by being consistent with one set of PHP syntax you ended
> up being inconsistent with another set; the brace-enclosed block.  In a
> brace-enclosed block statements are separated by semi-colons, not commas.
> And given your use of `case` we could argue that the `case`s are
> sub-statements of the switch.
>
> So I think both of our arguments as suspect here you are actually
> introducing a new syntactical structure with this switch expression that
> has no current analogue in PHP. It is unlike anything else that comes
> before it, and so I think it would be a mistake to be consistent in some
> ways but not in others. Better to introduce rules that are specific to th=
is
> structure that to justify the rules based on only partial consistency.
>
> Basically you are introducing the following syntax where the entirety is
> an expression:
>
> <expression-designating-keyword> [(<selector-expression>)] {
> <brace-enclosed-expression> }
>
> And we should explicitly consider what are the best rules to use for this
> rather than allow the rules to be defined based on consistency with
> something that is not like this new structure and thus potentially paint =
us
> into a corner in the future simple because we did not evaluate it fully.
>
> The question I think we should consider here is, what makes for a valid
> <brace-enclosed-expression>?  Is it a single expression, or can be be
> multiple expressions with a delimiter where the last expression produces
> the resultant value? Or can it even be multiple statements, the last of
> which produces the resultant value?
>
>
> We can limit to single expressions, but that seems, well, limiting.  If w=
e
> instead leave open the option for multiple statements =E2=80=94 which a s=
emi-colon
> would not conflict with =E2=80=94 then we leave open the future option to=
 support
> multiple statements in a block-enclosed expression.  But if we choose a
> comma we can never go down that path. Given this, *I think using comma
> paints us into a corner that using semi-colon would not.*
>
>
> As for fat arrows vs. colons, that too feels like misapplication of
> consistency.  A `case` is more like a ternary operator than an array
> initializer, and is much more like a switch statement. I fear that use of=
 a
> fat arrow will also paint us into a corner, but I cannot think of a
> specific example yet, it is just a fear based on my gut feeling. Using a
> colon would likely not paint us into a corner because it has already been
> used in effectively exactly the same context, e.g. the `case` statement f=
or
> a `switch`.
>
>
> So the question is, do we want to be consistent with an expression but
> inconsistent with brace-enclosed blocks, *or do we want to recognize that
> this is a new type of element and design the best rules we can for this n=
ew
> type of element?*
>
>
> We can either limit a brace-enclosed expression to containing only simple
> expressions =E2=80=94 which as I said seems too limiting =E2=80=94 or we =
can enable the
> future *potential *for multi-line statements in a block-enclosed
> expression.
>
>
> And that is my 200 cents on the matter. :-)
>
>
>
> What about break?
>
>
> Let's see this example.
>
> for ($i =3D 0; $i < 100; $i++) {
>     $x =3D getX($i);
>     doSomething(
>         $i,
>         $x,
>         switch ($x) {
>             case 0  =3D> 'ZERO',
>             case 1  =3D> 'ONE',
>             case 2  =3D> 'TWO',
>             case 3  =3D> 'THREE',
>             default =3D> break,
>         },
>     );
> }
>
> This should break `switch` or `for`? And if it breaks `switch` NULL shoul=
d
> be returned but this will be the same as omitting `default`. And if
> it breaks `for`, call to `doSomething()` will be incomplete because a cal=
l
> frame was already pushed to VM stack. As I know ongoing function
> calls can only be aborted by exceptions (and `return` should not be allow=
ed
> either, I need to fix that) so expressions must give something or throw.
>
>
> As I envision, it should break `for`.  And since the fact the call frame
> is already pushed does not stop a `throw` from working I do not see why i=
t
> should stop a `break` from working.
>
>
> And if for some reason that is too complicated, I do not see any reason
> why it could not throw an error in that context, because the refactored
> solution is trivial, and I would say, preferred for its readability anywa=
y:
>
>
> for ($i =3D 0; $i < 100; $i++) {
>     $x =3D getX($i);
>     $y =3D  switch ($x) {
>             case 0  =3D> 'ZERO',
>             case 1  =3D> 'ONE',
>             case 2  =3D> 'TWO',
>             case 3  =3D> 'THREE',
>             default =3D> break,
>         },
>     doSomething( $I, $x, $y );
> }
>
>
> BTW, when I code I use `break` wherever possible instead of `throw`[1-6],
> and only ever use `throw` and `try...catch` when I am forced to. So
> supporting throw but not  break here would require an additional comparis=
on
> after the `switch` expression for people who like me avoid `throw`, which
> is not ideal.
>
>
> -Mike
> [1] http://www.lighterra.com/papers/exceptionsharmful/
> [2] https://sidburn.github.io/blog/2016/03/25/exceptions-are-evil
> [3] http://xahlee.info/comp/why_i_hate_exceptions.html
> [4] https://www.joelonsoftware.com/2003/10/13/13/
> [5] https://mortoray.com/2012/04/02/everything-wrong-with-exceptions/
> [6] https://www.atlassian.com/blog/archives/exceptions_are_bad
>
>

--000000000000902ae005955fa72c--