Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:109612 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 74508 invoked from network); 13 Apr 2020 23:22:32 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 13 Apr 2020 23:22:32 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 080DE1804CE for ; Mon, 13 Apr 2020 14:52:04 -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, 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-yb1-f181.google.com (mail-yb1-f181.google.com [209.85.219.181]) (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 ; Mon, 13 Apr 2020 14:52:03 -0700 (PDT) Received: by mail-yb1-f181.google.com with SMTP id t10so6051583ybk.8 for ; Mon, 13 Apr 2020 14:52:03 -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=G7p83pPD8cWAvg4j5UMcVLun0imB20qru0USY+x6cOc=; b=FWD68yYwGGqY5pqNixpaVtCEQXXGCZ0PxRcyoBUu7k7sZLW6WHx+pA8xqNJq7i3ckl C6BSgLEPG8ceV1vwYoLKTxpOFTSkHNSz4bxW/02zU1tCXhBxRCNRItdki8SGBAHzGgkj 9UideegGHT63nSOKN4aZeDdMJ8DayGJd9qq1t/Bs4A0aEgTwwEjk/fNZewXGr4pbIhvJ xK6FvkZtNnlqEff+KoeHveHujG72hNOVNRFwOmMGAhSAGLHff5f1OAJjO2R7Ab1sLKN5 GtCU1n5nApyYDL3T22KjrjnzYmJjyo6Jph5e8FqQH51E2cCYniaCLIc03RdRjlEPTbh/ ygIw== 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=G7p83pPD8cWAvg4j5UMcVLun0imB20qru0USY+x6cOc=; b=Natt8RWbtn64195S7YsjSlXYvFKug41/zdtuFU/ypb6ZRjphB/iuP845GQFrtn3zpe 4R9LvYh3ZiyrbkUQRRJbWMEdbHu4lMwX7+JODlR5obXxkCpmLT+VZoBecaS7lIlIMPSL 1Sx9v0CVA8UDss/2C8I1xn0ZmaTLQePyHnNB2ZBYnHTd1llvcrQ9CflkXyjUm74xkl45 lx0XUz+zqChzqM6L7l/eWBmz2fWy5c3H0VkIvavAQvQP9HNa4Lpza0uijrxwM1p7uUIU jWk1Qjdc9S9wutTiQMfPnvM9JGxHmV4vNfJ2RSNnrIMP3vBUev17nHAmwqtuUgUh1W9l OosQ== X-Gm-Message-State: AGi0PuY+dhcMERvu67gk+K7oipbhWaRncuYyDDU/4e9Vsxtm/eXsa2TV 8jqJL2gD0YwOhXUJC8SMQDy+NOv347m0cJ1Fpli38uYY X-Google-Smtp-Source: APiQypJ8qt4wRS3Q374fcAETf5JC4gHgLJ8cJA18dSHurle8jTBTjaXEo84YyZ18C0oN+6RmuM/c17MUEQICwZT90os= X-Received: by 2002:a25:698b:: with SMTP id e133mr29776473ybc.367.1586814721015; Mon, 13 Apr 2020 14:52:01 -0700 (PDT) MIME-Version: 1.0 References: <6aebe21d-2137-885e-5ee9-99d4f917a7f9@gmail.com> <5071DCCE-4572-4B1F-A50B-832C5EA74795@gmail.com> In-Reply-To: Date: Mon, 13 Apr 2020 23:51:48 +0200 Message-ID: To: PHP internals Content-Type: text/plain; charset="UTF-8" Subject: Re: [PHP-DEV] [DISCUSSION] Match expression From: tovilo.ilija@gmail.com (Ilija Tovilo) Hi Rowan > Then why not introduce the match expression first, and add block > expressions (as a general concept) later? Mainly because I fear it won't pass and we'll end up with a handicapped match expression that can't be used half the time. > That way, we don't need all the special restrictions on when to use them I think that's a little overblown. We're talking about ~5 lines here. > the code above *is* ambiguous Whether or not some code is ambiguous depends on the grammar that defines how it's interpreted. "1 + 2 * 3" can be ambiguous if the precedence isn't clearly defined. Bison will check that your grammar is unambiguous, otherwise you'll get a shift/reduce or reduce/reduce error (as in there's multiple ways to parse your code). The suggested grammar defines that the semicolon can be dropped under exactly one circumstance: When the match is the first and thus only element of an expression statement. This is what Rust does too. This clearly needs to be described better in the RFC. > The only downside is that omitting the parentheses wouldn't be an error, > as with the closure case, it would just silently do nothing, which might > be rather confusing. That is true. Since array subscripts and function calls don't allow arbitrary lhs expressions the code wouldn't work without parentheses but at least you'd get a parser error. Ilija