Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:109900 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 66111 invoked from network); 29 Apr 2020 02:24:35 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 29 Apr 2020 02:24:35 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id AA8E81804DD for ; Tue, 28 Apr 2020 17:57:53 -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=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,RCVD_IN_DNSWL_LOW,SPF_HELO_PASS,SPF_NONE autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS11403 64.147.123.0/24 X-Spam-Virus: No X-Envelope-From: Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (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 ; Tue, 28 Apr 2020 17:57:52 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.west.internal (Postfix) with ESMTP id 490789A0 for ; Tue, 28 Apr 2020 20:57:52 -0400 (EDT) Received: from imap26 ([10.202.2.76]) by compute7.internal (MEProxy); Tue, 28 Apr 2020 20:57:52 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=pfvyOU rGt1mkV7p3RU8jYJ8nvacNbWeoMdmwUjtXEn4=; b=neC3IVh+AhQeZd2IWFERPN +DiLQXqY7AG4uUxoVPY6F68vr++0fX9vawv/dq5+U+Ee15Fod5PYQIkISYs6UBcR U2P1P/Q2yyjCEK/8FiR33+wUmYZ5XYvbknHBElbn1jI/iYTx/nqXmy47H7R7PR8o 4LaaLjGSEEtRk9dBpQucZfy98L9v0z/uzyL4Gg1dau+j0b3gWCWDAhMrQz5BF/40 WgQt9xHNnUhGsplL6DbxBX0xw+bpTytFsT0RFgLXBEujcTbOU79Y0R12L0zeK+3q dPDdghnQ7b+gHOm9Gzi4dMLtHzHyWK6RrP3ie+XDcQZYH2mD2xZ6OSsqk4b5yAuw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedriedvgdeflecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsehttdertderredtnecuhfhrohhmpedfnfgrrhhr hicuifgrrhhfihgvlhgufdcuoehlrghrrhihsehgrghrfhhivghlughtvggthhdrtghomh eqnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheplhgr rhhrhiesghgrrhhfihgvlhguthgvtghhrdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 7C1A114200A2; Tue, 28 Apr 2020 20:57:51 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-dev0-351-g9981f4f-fmstable-20200421v1 Mime-Version: 1.0 Message-ID: In-Reply-To: References: <5ea6e4b0.1c69fb81.cf3ee.2bbfSMTPIN_ADDED_MISSING@mx.google.com> <969c6150-a084-48c0-ae8f-b8043dce321d@www.fastmail.com> Date: Tue, 28 Apr 2020 19:57:30 -0500 To: "php internals" Content-Type: text/plain Subject: Re: [PHP-DEV] [VOTE] match expression From: larry@garfieldtech.com ("Larry Garfield") On Tue, Apr 28, 2020, at 7:37 PM, Levi Morrison via internals wrote: > > One issue that was discussed a few weeks ago, and led to the current syntax, was too many variations within the switch syntax; of course, trying to do it all in one syntax is perpetuating that problem. However, I think Rowan has suggested a syntax that may be sufficiently self-documenting. To wit, independent of rustmatch (above): > > > > switch ($foo) { > > case 1: { > > Many statements here. > > } > > case 2: { > > Many statements here. > > } > > } > > > > The curly braces are already understood by most PHPers to mean "a block of statements", and so it's a logical jump in this case. As Rowan suggests, the {} imply a break. To keep it simple we should probably not allow mixing and matching in a single switch. Either list-style (break required) or {}-style (break implied). > > > > That handles break; > > Sadly, it doesn't. That code is valid today: > > $foo = 1; > switch ($foo) { > case 1: { > echo "1\n"; > } > case 2: { > echo "2\n"; > } > } > ?> > > Which outputs: > 1 > 2 ... Well, crap. It just can't be easy, can it... Would it be too context-sensitive to have the {} version only work in strict switch? Or for that matter... is anyone actually using that syntax in the wild, or is it hypothetical? Viz, if the behavior of that changed in 8.0 (a major release), would that even break anything? Even 7.4 has a couple of "the behavior changed but seriously who was using this anyway?" points in it. Could we get away with just changing it for 8.0? I'm not sure if Nikita's "check the top 1000" script could handle something that subtle. --Larry Garfield