Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:109879 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 75534 invoked from network); 28 Apr 2020 16:58:17 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 28 Apr 2020 16:58:17 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 615101804C7 for ; Tue, 28 Apr 2020 08:31:30 -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.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,HTML_MESSAGE, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS15169 209.85.128.0/17 X-Spam-Virus: No X-Envelope-From: Received: from mail-io1-f41.google.com (mail-io1-f41.google.com [209.85.166.41]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Tue, 28 Apr 2020 08:31:29 -0700 (PDT) Received: by mail-io1-f41.google.com with SMTP id u11so23404678iow.4 for ; Tue, 28 Apr 2020 08:31:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=/vcpc7tdsS/RnkwSGbsZT17VlDgyO3zydhuXbOxZ6G4=; b=Wm9wi6n66gTNh97hcCu8QlfspU+sv4yqWacTYKFw4JqDaV1QzVUAkUDiS/NlfSwzFh 5KkPqV52OcvL6NY7uXgJcDMjC815MRf+vL2Jq9XMS31Ffxub8PIa5V3yFAe0WbVr/k3V 4AAHyjwPg7vguLaIMyWbcBtpknOLcEINZ9/UctCVHMZFSlCbQ/Ryb+dqUoUQR4qAw5DQ DoX0A8l506WPi5KUMtKWx6id5+4o78gVhz2kkQ/DkTYiW0aD7tHsx9tkTaobbYGaFDEN 737VFkdocT24d085jhZChOTVONOJHCWwSAhuCaVfCuQwLkbzca//eP2tRASoRNwAaWIp BJNw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=/vcpc7tdsS/RnkwSGbsZT17VlDgyO3zydhuXbOxZ6G4=; b=MYhzudHSqEq+igF+YvBqaTJZ1XlHwOnNtIz9jdZMkMHjSExbfzL+gvls/o5j+r2EOK rKwKZPhOwTaod6PUqHhwr2YELZNFWA5SMaPhBc8FYNxYSXH39QDsBz3Z9bqfn4pjVKFA w1C1JLZA30uNytCOus2epvRmaUv9dQ5kMgPKkPnEkWvdPOfp7nBESig4QsHjSsl2/OO5 MqyyxKWtsKGRnC3D5jf32q3VWwmXJesPn/hpLGjCRspnJYkw8YuXDK/uxF7jSC+UilAa DOFldkKlCrm1BCuA7Pyizytm0xgND+dgdUVPdaNtGX9LBmLhBpj0WKeVo5TqxwqpJz0Z qPYQ== X-Gm-Message-State: AGi0PuZffJGcv35FqYVG7uQ6qBAkboKhNTySiL4dWy0BbYxPHYMR7hFY n04h0doF9I+uY16H/g3NkEITtGhp6RSdZNXNOoWFKw== X-Google-Smtp-Source: APiQypIKGvEVI3i3fAXk+ACQbUEpCOgTN/4WsRuH568lLNAQWSz4yc0+ewCJySJUCAaeYY6EDdmf8yIGo2ASUVeYWLo= X-Received: by 2002:a5d:91c1:: with SMTP id k1mr25124877ior.8.1588087888546; Tue, 28 Apr 2020 08:31:28 -0700 (PDT) MIME-Version: 1.0 References: <5ea6e4b0.1c69fb81.cf3ee.2bbfSMTPIN_ADDED_MISSING@mx.google.com> In-Reply-To: Date: Tue, 28 Apr 2020 16:31:16 +0100 Message-ID: To: PHP internals Content-Type: multipart/alternative; boundary="000000000000780e4405a45b86c4" Subject: Re: [PHP-DEV] [VOTE] match expression From: rowan.collins@gmail.com (Rowan Tommins) --000000000000780e4405a45b86c4 Content-Type: text/plain; charset="UTF-8" On Tue, 28 Apr 2020 at 16:10, Bob Weinand wrote: > I think you should first think about why the "case" needs to exists at > all. In particular it exists to distinguish goto labels from the case > expressions in switch. With match, match restricting statements (and thus > goto labels) into { brackets }, it now is not necessary to do such a > distinction and we can get rid of the extra token. > That may be obvious if you're used to writing parsers, but to users, the case keyword is simply how switch statements work. Removing it just makes the new statement look less familiar and isn't justified by the aims stated in the RFC. > "=>" is logical as well, we use the return value of the expressions (see > fn() and array syntax), the colon is exclusively used for pure statement > boundaries. > You've missed the context of my e-mail: I was explicitly discussing a hypothetical syntax that *doesn't* resolve to a value, and where the colon *is* introducing a statement not an expression. > The comma is necessary for the expression syntax at least (consider > match($a) { 1 => 2 + 2 + 2 => 3 } - is this now match($a) { 1 => 2, (2 + > 2) => 3 } or match ($a) { 1 => (2 + 2), +2 => 3 } ?) You may argue to make > it optional behind a statement block though. Again, expressions are explicitly out of scope for this thought experiment. As such, the result of every case is delimited either by a closing brace or a semi-colon, and the above example is simply a syntax error. As I've said many times now, I really like the match expression, with the current syntax, as a pure expression. I was explicitly addressing the question of why I think a straight-forward switch replacement would not look the same if we weren't trying to squeeze two features into one syntax. Regards, -- Rowan Tommins [IMSoP] --000000000000780e4405a45b86c4--