Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:112507 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 64110 invoked from network); 14 Dec 2020 23:31:47 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 14 Dec 2020 23:31:47 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 566701804C6 for ; Mon, 14 Dec 2020 15:02:33 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net X-Spam-Level: ** X-Spam-Status: No, score=2.5 required=5.0 tests=BAYES_05,SPF_HELO_NONE, SPF_SOFTFAIL autolearn=no autolearn_force=no version=3.4.2 X-Spam-Virus: No X-Envelope-From: Received: from panel.brollopsguiden.se (panel.brollopsguiden.se [87.237.210.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Mon, 14 Dec 2020 15:02:32 -0800 (PST) Received: from [192.168.7.11] (213-64-245-126-no96.tbcn.telia.com [213.64.245.126]) by panel.brollopsguiden.se (Postfix) with ESMTPSA id 258771D000A2; Tue, 15 Dec 2020 00:02:01 +0100 (CET) To: Sara Golemon , Doug Nelson Cc: Marco Pivetta , Larry Garfield , php internals References: Message-ID: Date: Tue, 15 Dec 2020 00:01:49 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit X-PPP-Message-ID: <20201214230201.19567.16451@panel.brollopsguiden.se> X-PPP-Vhost: brollopsguiden.se Subject: Re: [PHP-DEV] [RFC] Short-match From: bjorn.x.larsson@telia.com (=?UTF-8?Q?Bj=c3=b6rn_Larsson?=) Den 2020-12-14 kl. 22:23, skrev Sara Golemon: > On Mon, Dec 14, 2020 at 2:24 PM Doug Nelson wrote: > >> Both you and Sara at different points have talked about thinking was bad >> practice, but I've not read anything compelling about why it should be >> considered as such. >> >> > I'm not a full -1 on the concept (especially as match(true) has the > convenience of returning a value), but it's very square peg in a round hole > to me. > > At the end of the day though, that's a style choice and not one I have any > business imposing on anyone, and certainly within the context of this diff, > the actual change is trivial. It's sugar for match(true) that looks like > match. /shrug > > I might suggest broadening the scope to include `switch` as well though. > If we're going to codify match(true) as a pattern, we should at least be > consistent about it. > > -Sara > I think it's a good point to keep it consistent with switch, i.e. if moving forward make the same change in switch. Then when mixing and matching on at least don't need to remember where true is needed... r//Björn L