Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:109438
To: Ilija Tovilo <tovilo.ilija@gmail.com>,
 PHP internals <internals@lists.php.net>
References: <047092C7-84FB-42AB-8084-7B83F76F55C1@me.com>
 <CAO11TfFk+OT6uC0vk2B9Y_W+w9uh33NPUcO8gD6sLJB=2qd5zw@mail.gmail.com>
 <026AF97E-ED0C-411C-8942-7DA7CC9705DB@me.com>
 <b59d6c73-7b6a-20a0-44c1-69fb0f8a6525@gmail.com>
 <CAPyj-LA8U2whEuQ8mQmTwqOpu0WyvexAYq3+AJm78fUTB7Wx1Q@mail.gmail.com>
 <34ce624e-7d00-4f63-2c4f-da125deb65b8@gmail.com>
 <CAPyj-LCdgjmc2ff_uw5Qdw3Z7R5-gHk8SAkCWvY5Dg-eA0bsJA@mail.gmail.com>
 <b406b052-d496-4e7a-aaa8-65736eccd5f4@www.fastmail.com>
 <CAPyj-LB=DR2qJ5CP1pBCtUGEKWCW5b_wxyz0=nHWKGpxgC+8QQ@mail.gmail.com>
Autocrypt: addr=smalyshev@gmail.com; prefer-encrypt=mutual; keydata=
 xsJuBE9mqaARCACFSqcGmNunkjQQu3X+yXnTmFeEkvM4JXZTOBdR8aEevNGmmFEfyvjaDjWi
 9hcwp4E/lYtC+P7VsVjM1OSX9eq0jC/lGL0ZyRXek+mNy0n5H1NSuTpf9Y18LMqhc4G+RU+L
 cNiZ9K0DJuOOvNLPxW7OHZguxb3wdKPXNVa2jyRfJAKm2uaJJMT1mTmFT9a0Q8SKr+mUrrJk
 uG0H2o6SzrKt8Wwoint1eh67zVsJaJtQFchnEZnlawIcqP2yC4nLGR3MkubowxoEBYCZet18
 aHVVRbvpG2Qtob8Lu5xrsGbmXymTkHTdpvkfcJFADa8MzOL90zOxXwbGfbIZOlh5En8jAQCX
 lfnx2eQL3BSW/6XANa51dbWiEp1d1BAkpGKtZvlk0Qf+M9WAi+9aXMe3xP5krxtgnRNUf2WN
 6Zdy2MxL1RRJCFbytLhl0ronC49BsGYVGshdEH8xhBbiIOJKuVZ/DTl9bEm7P9c7CC7iJyVC
 khUAhouH6xzZQNLR+RU+QebYzXypVfl99Qk7EdMmr/WAZCHLuvanyqepC5EBsa3VnAfQemSN
 oBeGBKWWLiOsPjvS72+y1z4RUMAfXHn4l/sFMt8zt7/74AmJPwZquV41p4mPO12V4+xPyc6R
 sB84sfsk2QVivU8w8AkvGQeYjXoz7Iwao95+fWteVzZ36KRQvUckP8pGjHlDXnHxJ0HI1I/k
 OBZSjwRwUf0dd73y6erPhbLk+gf+NdI3H9KGJBzG5/rVyWKwUeQ9d5ud4jTJRkQGvAP5pg76
 vEa9dogbpe4W5Z+0BfbiJSnQmQWSHiZddj/t33ptbup44Ck6ZTgdlmFYMLF1hR47PIZTDKER
 EuKYGci/vq8snZvEJP9YCw/TtiHcMdrMKcY/+Lp8lQO0GHLPB9glVhnC0db6l1Xpg1CMI8/R
 ozBMcij30EgATggC/y2zbiqAFoS9FN9nXPbe4phStqABEyeZ+nXudt7PUYTjVgcrqo8bHZCi
 sBobWC7OnKyUzxVxzUeuPkIfmZuzkLaMw2McQdvwwsNvQ0DzaLP30c1Xsm/7EIYJcOWpzlVJ
 5QrdmE0/Bc0yU3RhbmlzbGF2IE1hbHlzaGV2IChQSFAga2V5KSA8c21hbHlzaGV2QGdtYWls
 LmNvbT7CegQTEQgAIgUCT2aqtAIbAwYLCQgHAwIGFQgCCQoLBBYCAwECHgECF4AACgkQL3lW
 vF2gS12XMwD9HuRIolSwIK77u8EY461y2u6sbX36n5/uo/LDQuxoi3sA/0MvpnvzOhv9Iufv
 vsZEj3E7i3h+iD5648YMwfTFCij+zsFNBE9mqaAQCADfZPMpjZkkGZj3BY/7ApoLq4mwqzbh
 +CpLXwNn20tFNvSXfb8RdeXvVEb7Scx+W9qYpiaun2iXJgCVH8fgpZpR856ulT1q6uCG++CX
 ubEvip/eJkZl93/84h04KQJwsgOrAh0Om3OePRn8Pr+++0LNS0EL8uX/YHeTOGOnnmTqYTey
 SBVFdov6L4mepddfjekicKQqhL7mZh/xuq29JijT0uNNX8v4vDWQDu5dlAcdd+uB3gcXMD/P
 ginD11zp+6wtrWCm/+yBqpvDwXQX5PGUnwvbRfl7Ay3MmwmoXiecZMg0dwTSc7e0lhB4HGRH
 ZdBMJB4rHUVGdzqujK/ctOvrAAMFB/0Utb76Qe6sCMlHxVAmeE/fbo7Pi05btZ/x01r67dHf
 aMSP0riCKJ7M0OW+jAXtu9+z/BVnYisW67WWfxl2cS5tZDgiHgJARXWUOO72+sScHP8KQmTl
 1z16gyKbwY3SmyBkwcpOL35nhUWNLy93syPoY6sZUTikr2bZYukHDQ33XBPs4e6MbWKfsa9q
 aVmnlOF3k5UqChjutfHaEa4Q7VP4wBIpphHBi9MI16oJIzzBPbGl2uoedjwiZ6QeQZnSuOVY
 ZxU2d3lRA8PrtfFN1VSlpEm/VcAvtieHUYWHN0wOu+cp3Slr5XJVNjTjJhl28SlinMME54mK
 AGf2Ldr/dRwXwmEEGBEIAAkFAk9mqaACGwwACgkQL3lWvF2gS126EQD/VVd3FgjLKglClRQP
 zdfU847tqDK4zJjbmRv5vLLwoE0A+wbrQs7jVGU3NrS0AIl5vUmewpp2BKzSkepy23nWmejw
Message-ID: <97b547d2-029d-7da0-8755-4693ba40b649@gmail.com>
Date: Sun, 29 Mar 2020 15:22:10 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <CAPyj-LB=DR2qJ5CP1pBCtUGEKWCW5b_wxyz0=nHWKGpxgC+8QQ@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] switch expression
From: smalyshev@gmail.com (Stanislav Malyshev)

Hi!

> 1. It uses the same AST, code generation and opcodes as the switch, I
> don't agree that it is significantly different than the switch that we
> already have.

This is reasoning in wrong direction. Nobody cares which opcode it uses.
It is significantly different *for the user*, the fact that it may
compile into same opcode means nothing to the user.

> 2. Adding the `match` keyword is a breaking change, not an insignificant one.

I thought with AST we should be past banning keywords as function etc.
names, aren't we?

> 3. If we can fix the switch statement semantics in the future the two
> will only differ in that one returns a value and the other one
> doesn't. This is a much smaller distinction than functions/closure.

We don't need to "fix" anything in the existing switch, and likely
couldn't because of immense BC breakage it would cause. If you want
different switch, you better start with different keyword.

> 4. If we'd every want to add pattern matching, we'd still have a
> keyword available to us.

What you proposing essentially *is* pattern matching, just very limited
one. Extending it would be a natural development.

> type coercion. This would make it a replacement of the switch
> statement instead of an addition.

I don't think we need replacement for switch statement. Adding simple
matching expression seems to be a good idea, but please don't let it get
out of the way and turn into something that is too complex and
controversial and be buried under details that nobody actually needs.
It's better to have sometime simple.
-- 
Stas Malyshev
smalyshev@gmail.com