Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:110186 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 39671 invoked from network); 16 May 2020 16:27:28 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 16 May 2020 16:27:28 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id CC18D1804E1 for ; Sat, 16 May 2020 08:05:10 -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.2 required=5.0 tests=BAYES_20,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-wr1-f47.google.com (mail-wr1-f47.google.com [209.85.221.47]) (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 ; Sat, 16 May 2020 08:05:10 -0700 (PDT) Received: by mail-wr1-f47.google.com with SMTP id e16so6759926wra.7 for ; Sat, 16 May 2020 08:05:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=87+CtGcTrlZbFfsq4b2ZsvcA0VX9YYiBztJioao8gI0=; b=mRV8mDRWyz5MUXSiPq8Y5UPBwEqKDBLxuhfbiMPRxpkbCB637RhlHjdeN1H8CReRWM +Gl6FAySVJGGuy/qhm4QwxyuSIISAvlx4bw8WRA8+PwmjJB0V+tg3FARcOk6PUqqg3/N pdKb9tkZxQ554B5CHev2TcS9p4d7pFvwpkyygGap79em9eJjnhSaC2vBVL6owdqTcw6X 0K3W9DwZo5lRVmmqomYdsD5a6gPGOSq0Sw/Z3o2NSqiJx1mr/BQg5IsQlCysYQrNA9Xy gz6JryjapqwKy2A14CxNV1gEGMz8ZCeTJVra1Em7yM9EZQ9anPXrCbRaH5n6c4NozqMB BIRw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=87+CtGcTrlZbFfsq4b2ZsvcA0VX9YYiBztJioao8gI0=; b=Z+Xqg5D0JIAUsHI5FuMYdsRtVUsfkXX3Vn6WKS/B9d2TtBXU099Shqojpjc4dDPZnO mnjDEGZMZ/2wGuEF0/sDMS6WziOzWeaMQs125KBXuDtJZIpx/xiDeOyolJbE5wwl6kTD w6i+fqMohEN0+Y/AcOm7Dav7YP///9J6FfqheHg2i3ZM3fxraKdFL7KVdAE6/qbtdjgp SooPlP/0J0yW0s8Bx0VV+Kmj8Q5e6i/426oo2wKF2J4qs3f+PCL2o4GMdlkywKYW3UQe LXlKQZ5F2whnZERkGLrCRUP8IjYXMXLfqOlvVryH02PjaoZvzTGCXMzSaLNIHIiy1Vae h9NA== X-Gm-Message-State: AOAM531BYsWe2+ScNLErzvIJF68V2p9FwcOjqRmWOrXZtyVO7DnR7kSK Dofuvkkk+BSSYcDy2Uwf83pcDAao X-Google-Smtp-Source: ABdhPJyZp6POq5tEjJ+KwOW0TPH9FGhReeucP8tywWE45Y7F6c3mNLxu3dFGY21E0P4w3Zgh+H7XKg== X-Received: by 2002:adf:e748:: with SMTP id c8mr9889087wrn.355.1589641508012; Sat, 16 May 2020 08:05:08 -0700 (PDT) Received: from [192.168.0.14] (cpc84253-brig22-2-0-cust114.3-3.cable.virginm.net. [81.108.141.115]) by smtp.googlemail.com with ESMTPSA id g187sm8017063wmf.30.2020.05.16.08.05.06 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 16 May 2020 08:05:06 -0700 (PDT) To: internals@lists.php.net References: Message-ID: <8affa1f4-783c-f5bd-044f-1e0b2d8dd8e3@gmail.com> Date: Sat, 16 May 2020 16:05:04 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB Subject: Re: [PHP-DEV] [RFC] Guard statement From: rowan.collins@gmail.com (Rowan Tommins) On 16/05/2020 10:13, Pavel Patapau wrote: > I want to propose new syntax addition - guard statement, that executes > code only if expression equals false and must contain control-flow > changing code, and written a respective RFC: > > https://wiki.php.net/rfc/guard_statement Hi Pavel, This certainly seems to be a "problem space" which several people want to explore, but I'm not quite convinced by any of the proposals so far. I read through the links in your RFC, and a few articles about Swift's "guard" syntax, and have a few observations: * An important defining feature of a guard clause is that it occurs *before* any of the logic of the function. Some languages have syntax to codify that, putting guards or pre-conditions as part of the function's header, rather than in its body. * Another defining feature is that guard clauses should be simple, getting easy cases out of the way early. Having "guard ... else" take a whole block of statements, including other flow control, makes it feel less like a guard clause, and more like normal flow control. * Swift's "guard" clause is used for assertions which affect the static analysis of the code. Most notably, "guard let x else { return; }" can be used to check an Optional value, and the compiler will allow that value to be used in the rest of the function without further "unwrapping". That explains the requirement that the guard clause aborts the flow of the function (including calling a function with a "Never" return type, as John Bafford points out). There's not really any equivalent of that in PHP, so including similar limitations feels rather arbitrary. * As with Ralph Schindler's e-mail, Perl and Ruby are being slightly misrepresented here: they don't have explicit syntax for guard clauses per se, they just have more ways of spelling "if", which is useful for making guard clauses read nicely; that includes "unless", which just means "if not". Regarding the specific syntax, I agree with others that "guard something else return" doesn't read particularly naturally, although opinions may differ here - I found one blog post about Swift saying: > It’s easiest to read the above code as: /“Guard that/ number /is greater than or equal to zero, or else, return nil.”/ See how that reads quite naturally? [Reinder de Vries - https://learnappmaking.com/swift-guard-let-statement-how-to/] One thing I'd like to see on proposals like this is more explicit examples comparing to current language features. For instance, why would (or shouldn't) someone use: * "guard( condition ) else { throw new Exception; }" instead of "assert( condition );"? * "guard ( condition ) else { return; }" instead of "if ( ! condition ) return;"? * "guard ( condition ) { complex logic }" instead of "if ( ! condition ) { complex logic }"? Regards, -- Rowan Tommins (né Collins) [IMSoP]