Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:109600 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 9982 invoked from network); 12 Apr 2020 22:10:19 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 12 Apr 2020 22:10:19 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id B47231804CE for ; Sun, 12 Apr 2020 13:39:33 -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.7 required=5.0 tests=BAYES_05,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-f172.google.com (mail-yb1-f172.google.com [209.85.219.172]) (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 ; Sun, 12 Apr 2020 13:39:33 -0700 (PDT) Received: by mail-yb1-f172.google.com with SMTP id h205so4274603ybg.6 for ; Sun, 12 Apr 2020 13:39:33 -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 :content-transfer-encoding; bh=O21NfW9AA2u75nXVKqXBTdp2hNBnL0L2fdn5Sd8McVc=; b=OaXmxSjyClqHQ4eze6sOIkQQR/iPonUc6xmCMdhZQblpMenNSzqG7iq0qyr1S038DL yh5Qd2wC8Ukhs4dJQY5/3vrnxAGBwFAgH6hqFRYzU86+GGaNfjhX+nWQ3XYwXMYxzyRi XLH0gGo5q4ONYmyagEgubQ2MyXIPMTFELiHvKfUwINjM7Nj+R0l54rX4taRTJvOuknYT zTL036VB4iXjGm0GIOSRuufyZS+Ai4lETMZpQEScq28Nyv3SJxBwvbQ1xrIzuDCvMXx7 5EuhNIwb0EQf9ZSwmDhbN7NjImrzU4xkWphLrirGVZodN3gDeHTGW/vyJkDcfMsEtX4B n2bA== 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:content-transfer-encoding; bh=O21NfW9AA2u75nXVKqXBTdp2hNBnL0L2fdn5Sd8McVc=; b=c81nD/GJj6MqemaQ/hnU6A6VHUNQK3rDsMcDLg6NsQ76V/VlLeFaLwVH/t5c0EFNBB RaZYu952AIlYrRSXa6o3IpcSdYZnuzaxTXiK8wvTdTsdW54ephs4BN+PEMNBptC6d7M/ 1egs9usxoRIliGYjEV8os9Kfoib7xEY0QF9y0ONets/JSmfwlF8BdWP0HjuX/OmK+MSJ Q9UZLEYynceuHphbHYpLDq5R7AToysL4vfvBJouQmGFqQsMrFgBILZ9qubdlJJqYPnra loWydzl8dvbWjYpQW+ssQuS5p1kUJE4geKpsEKmzbbaOBNfCjPvhfHtLKhTg5hVqi9hM 5xbw== X-Gm-Message-State: AGi0PuasAAQulRSdDtGd4pRjyvrHZF19sqfEaJMl42d8Tg4mkTLnG3zB o4Nd5sSdGA47nwmVskMCKILZ7qsNTFXo3nQuzANvHi2C X-Google-Smtp-Source: APiQypJT04J8QFjXL3/7Q/GInzZZBdsVO6wiLp5yDdxSuPXPBDrvDM/28lT+VMeVDJh5QWkw2lHNwEALJZaA4AC2R3A= X-Received: by 2002:a25:3bd0:: with SMTP id i199mr21603164yba.297.1586723972391; Sun, 12 Apr 2020 13:39:32 -0700 (PDT) MIME-Version: 1.0 References: <4d5a347b-8d9d-43fd-b811-3cb6c13ad06a@www.fastmail.com> In-Reply-To: <4d5a347b-8d9d-43fd-b811-3cb6c13ad06a@www.fastmail.com> Date: Sun, 12 Apr 2020 22:39:20 +0200 Message-ID: To: php internals Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [PHP-DEV] [DISCUSSION] Match expression From: tovilo.ilija@gmail.com (Ilija Tovilo) Hi Larry > That not only alleviates the need to support multi-line blocks, it keeps = the match statement itself clearer to understand at-a-glance, and encourage= s the definition of named, testable, small blocks of code (ie, functions wh= ether anonymous or not), which is a net win on its own. I'm generally not a fan of this approach. I think it's unrealistic to expect users to move code into a separate function just because it takes two lines of code instead of one. People can't be forced into writing clean code and my fear here is that they will just revert back to using what is more convenient. > I'm fine with match() always being strict comparison, regardless of the t= ype mode. However, it should probably be made more explicit in the RFC that= it is unaffected by the type mode. That's a good point, I will add it to the RFC. > Possible addition: Make the match input optional, defaulting to "true". This has been proposed before. I do like it but I'm not sure if other peopl= e do. > I would strongly recommend removing the block statement support, as it ju= st muddies the water. As mentioned in my e-mail to Rowan, we'll probably never agree on this point. At the end of the day, you might be getting a feature you don't have to use. It barely adds any complexity to the language but will make other users happy. Thanks for you input! Ilija