Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:109852 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 10680 invoked from network); 26 Apr 2020 09:52:29 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 26 Apr 2020 09:52:29 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 019B51804B4 for ; Sun, 26 Apr 2020 01:25:08 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_40,SPF_HELO_NONE, SPF_NEUTRAL autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS20694 188.94.24.0/21 X-Spam-Virus: No X-Envelope-From: Received: from scarlet.netpirates.net (scarlet.netpirates.net [188.94.27.5]) (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 ; Sun, 26 Apr 2020 01:25:07 -0700 (PDT) Received: from pd9e63e57.dip0.t-ipconnect.de ([217.230.62.87] helo=[192.168.178.42]) by scarlet.netpirates.net with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.3) (envelope-from ) id 1jScb5-0006JL-OE for internals@lists.php.net; Sun, 26 Apr 2020 10:25:07 +0200 To: internals@lists.php.net References: Reply-To: internals@lists.php.net Message-ID: Date: Sun, 26 Apr 2020 10:25:05 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] [VOTE] match expression From: sebastian@php.net (Sebastian Bergmann) Am 26.04.2020 um 10:15 schrieb Marco Pivetta: > By enforcing only expressions to be on the right-hand-side, we get some > nice side-effects too: > > * no need to discuss `continue` > * no need to discuss `break` > * no need to discuss `return` > > Overall, that would be a win-win. Makes sense to me. > A point has been risen about the fact that using closures increases memory > usage and stack frames: that's a compiler optimization concern, and > probably also a minor one, since I'd discourage procedural code on the RHS > anyway :-) Agreed. > I'd be voting YES on the RFC if the blocks were gone. Same (I think).