Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:109844
Content-Type: text/plain;
	charset=us-ascii
In-Reply-To: <CAPyj-LDo0AafB9FZoxUHU35Y7PAU+DYb4qGm+KV2-eF5KvNmng@mail.gmail.com>
Date: Sat, 25 Apr 2020 13:07:11 +0200
Cc: PHP internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID:
 <VI1PR02MB4703B277F44D74A864B85113E2D10@VI1PR02MB4703.eurprd02.prod.outlook.com>
References: <CAPyj-LDo0AafB9FZoxUHU35Y7PAU+DYb4qGm+KV2-eF5KvNmng@mail.gmail.com>
To: Ilija Tovilo <tovilo.ilija@gmail.com>
MIME-Version: 1.0
X-MS-Exchange-MessageSentRepresentingType: 1
Received: from [IPv6:2001:7e8:cba2:c100:1d9:c36:bbf3:36a6] (2001:7e8:cba2:c100:1d9:c36:bbf3:36a6) by PR3P191CA0060.EURP191.PROD.OUTLOOK.COM (2603:10a6:102:55::35) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.13 via Frontend Transport; Sat, 25 Apr 2020 11:07:16 +0000
X-Mailer: Apple Mail (2.3445.104.11)
X-Microsoft-Original-Message-ID:
 <08105589-8780-426C-A254-1B2F30B5B8CC@hotmail.com>
X-TMN: [bSYCr6MriWOiGWnuU63qI8JkpuLNGlJLNVCy9QcLzvUHuuMsLv2UGWo8cSwFUPZs]
X-MS-PublicTrafficType: Email
X-IncomingHeaderCount: 50
X-EOPAttributedMessage: 0
X-MS-Office365-Filtering-Correlation-Id: a9b2bc46-1e8d-456b-55d1-08d7e908d0a6
X-MS-TrafficTypeDiagnostic: DB5EUR01HT082:
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info:
	owktVfrZtU1p5qaszXcqByemaV6sdozXFe09qhx149EskkbKU84mjzxtArsOw63NG6FM2MfzCVOzRf1CNYenmIRZhu+g8hQ0PDLyOT3HOlZi6lQWX6Ov8lAIksv7449c0fHiGef0Tl//L+vW+/lo4IMgoGwAIkNqDcOC8oajspzpEPm8hgdoWH/2m+H+367u6jDl6Q2rc7LAqI659BtnNQwA7UIFHEkITxc6CEwzjEPVSpZIUCIGhDwvnsnFbDtz
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:0;SRV:;IPV:NLI;SFV:NSPM;H:VI1PR02MB4703.eurprd02.prod.outlook.com;PTR:;CAT:NONE;SFTY:;SFS:;DIR:OUT;SFP:1901;
X-MS-Exchange-AntiSpam-MessageData:
	uYT/auFea9jhR0gSO4XCgpuGB7qEGihhc/+peuGUWnoD72mVul9TPr2lxvGSn4oYUslpDU0hvCGftlIKIsBTbqvcTB/1QcW4QLL3v8AWQltVhg5420Q0DC2XWsKwejeBdoB9tp3lMDcCUvwp0eXJTxqGNBtHeiN/Pjb555zVSBLUGfi5wkqrvJJ9kvCuI2KDASm0WgnEuoMc4gp2j700Bw==
X-OriginatorOrg: hotmail.com
X-MS-Exchange-CrossTenant-Network-Message-Id: a9b2bc46-1e8d-456b-55d1-08d7e908d0a6
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Apr 2020 11:07:17.1163
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-CrossTenant-FromEntityHeader: Internet
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg:
	00000000-0000-0000-0000-000000000000
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5EUR01HT082
Subject: Re: [PHP-DEV] [VOTE] match expression
From: bobwei9@hotmail.com (Bob Weinand)

> Am 25.04.2020 um 12:39 schrieb Ilija Tovilo <tovilo.ilija@gmail.com>:
>=20
> Hi internals
>=20
> I have opened the voting on the match expression RFC. It will end on
> 9th of May, 2020.
> https://wiki.php.net/rfc/match_expression
>=20
> Here are the last changes:
>=20
> In the last update I mentioned allowing return values in blocks.
> Unfortunately, we discovered some technical difficulties (memory
> leaks) which are very hard to solve. Nikita is experimenting on a
> possible solution. There was also a fair bit of backlash over the
> syntax. Thus I have decided to move block expressions to a separate
> RFC. Note that blocks with just statements remain part of this RFC.
>=20
> The "duplicate condition" warning mentioned by Dan was removed due to
> the arguments made by Tyson.
>=20
> I have also moved the optional semicolon for the match in statement
> form to a separate vote as this was another controversial part of the
> proposal.
>=20
> Furthermore I have added another secondary vote for allowing to drop
> (true) conditions as that was suggested multiple times:
>=20
> match {
>    $age >=3D 30 =3D> {},
>    $age >=3D 20 =3D> {},
>    $age >=3D 10 =3D> {},
>    default =3D> {},
> }
>=20
> // Equivalent to
>=20
> match (true) {
>    $age >=3D 30 =3D> {},
>    $age >=3D 20 =3D> {},
>    $age >=3D 10 =3D> {},
>    default =3D> {},
> }
>=20
> There is a separate poll for specifying the reason for a "no" vote.
> Let me know if there are any other reasons so I can add those to the
> poll.
>=20
> A personal thank you goes out to Tyson for his guidance!
>=20
> Regards,
> Ilija

Hey Ilija,

while in general I'm okay-ish with match using a strict comparison,

shall the "match { $cond1 =3D> {}, $cond2 =3D> {} }" syntax be strict or no=
t? I would do a simple truthiness check in that particular case (which IMHO=
 is also consistent as there is no explicit value it's compared against).
That way it would essentially have the semantics of a chained ternary witho=
ut being illegible.

At least as match {} without explicit expected value is effectively a boole=
an comparison (doesn't feel really like a strict value comparison), it shou=
ld also behave like a classical boolean comparison.

In general, apart from that very last change (I think you should have given=
 it at least 1-2 days of consideration before starting the vote), the RFC i=
s nice and provides a concise syntax for something which usually is quite u=
glily expressed.

Bob=