Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:111402
To: "internals@lists.php.net" <internals@lists.php.net>
Thread-Topic: Allow dropping (true) from match expression conditions in 8.1
Thread-Index: AQHWbn2Ozv6Nwx7o0UW9HKWL6piDRg==
Date: Sun, 9 Aug 2020 19:10:13 +0000
Message-ID:
 <DM6PR07MB6618C33644F699CAA039BA96F9470@DM6PR07MB6618.namprd07.prod.outlook.com>
Accept-Language: en-CA, en-US
Content-Language: en-CA
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-Network-Message-Id: eab46d2e-0fe3-4626-3792-08d83c97d84a
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Aug 2020 19:10:13.8326
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7NAM10HT049
Subject: Allow dropping (true) from match expression conditions in 8.1
From: tysonandre775@hotmail.com (tyson andre)

Hi internals,=0A=
=0A=
https://wiki.php.net/rfc/match_expression_v2#allow_dropping_true=0A=
mentioned this in the future scope.=0A=
=0A=
```=0A=
$result =3D match { ... };=0A=
// Equivalent to=0A=
$result =3D match (true) { ... };=0A=
```=0A=
=0A=
https://externals.io/message/110243#110292 summarizes the current status=0A=
=0A=
> 80% were in favor of this feature but it's also worth noting that only=0A=
> 20 people have voted. To avoid risking another rejection and thus the=0A=
> RFC being delayed for a year I'd rather move the feature to a=0A=
> different RFC. Also, the feature being included in the first draft was=0A=
> a rash decision in the first place (completely my fault). There are=0A=
> multiple ways to deal with the value comparison (e.g. do type coercion=0A=
> like the switch or type-error on a non-boolean value) but they haven't=0A=
> been discussed at all.=0A=
=0A=
I'm not the RFC author, but discussing alternatives was brought up 2 months=
 ago.=0A=
I'm in favor of strict equality, but would be fine with loose equality.=0A=
=0A=
Personally, I feel like adding a type error on a non-boolean value would be=
 inconsistent=0A=
with the short-circuiting behavior I'd expect from match.=0A=
Additionally, if the first conditions are almost always true,=0A=
this would make bugs in the last conditions harder to find.=0A=
=0A=
People might intuitively expect `match {` and `match(true) {` to do the sam=
e thing=0A=
when refactoring code, and be surprised if loose comparison cast behavior i=
ntroduces bugs after a refactoring=0A=
(e.g. `match { $arrayOrBool =3D> ..., default =3D> process_array_or_false()=
 }`)=0A=
- Maybe adding a loose comparison equivalent for `match=3D=3D{}` or `match~=
{}` or something (both with and without an expression) would help.=0A=
   I can see use cases for it but I'm not sure what others think or if it'd=
 be worth the language complexity (e.g. already possible to cast arm condit=
ions to booleans)=0A=
   (e.g. dealing with user input that may be an int or stringified int from=
 db/user input/a remote API call)=0A=
=0A=
Thanks,=0A=
- Tyson=