Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:110113 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 35887 invoked from network); 10 May 2020 20:20:06 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 10 May 2020 20:20:06 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 271631804C4 for ; Sun, 10 May 2020 11:56:21 -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-oi1-f172.google.com (mail-oi1-f172.google.com [209.85.167.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, 10 May 2020 11:56:20 -0700 (PDT) Received: by mail-oi1-f172.google.com with SMTP id c124so13062166oib.13 for ; Sun, 10 May 2020 11:56:20 -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 :cc; bh=hnzOKK1V2L9baPSUsLtfOAAbWltQOS28M99WkpzKPkA=; b=UshsSgVjtHDlL3orekGsK8sZQiwHnPxasoU6+HEz/v8DL514MoqpFe0k37OcDvzFvH pmdLGKmPdxRhDyaoEGZB8pmdzMvBGPiBLbdK03A3h2SZHZz4qHMly/LmzRlKzs8DBNg0 u56ohL49NWDX7k0FgLEIehgT4J+S7duF0okwvZtk6kNoezEdiP3PWTAH4q/HnAEVo8K1 RinfIGzzN5WoIoBKbJq/apKnYQlZHjH8JGtx4dxiDQQuIqCeId3w8kBZyLyR8HyqDFvF xR/lBeO8JRyIxI6cuSweBIK+HdY0xS79GhsXRGKTwhQwTWjIY3X6o5xaDvdRbVzVgANu YL0Q== 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:cc; bh=hnzOKK1V2L9baPSUsLtfOAAbWltQOS28M99WkpzKPkA=; b=LWty12sKh8yuCUf+NSwrSzQOOea1beOv0USV+UjpRwvAJ1vlFnOAsXWeP8PrwrwRQG 36DlE4/zhs8GlzdNiSeWo5tvD7wMYgnvgfXJEwL6RITSZIlA11Z9iasDbBrs92ww5Qro 2whjC1Ejs3Eg8ucmJbwJnXPgax5R4/imW9NyIbsg+yeCy3J9WWx/1kx71l06kUoiJyRW dPtyFdETkPPp0JZR3M1dEf2V7gT56uy7WvlXMIxRCAa8CbLYlRmKbDUl1HWxhPb/Rro3 MEUwd7DMr7UZt6+tXYXCn9R0TxVXUzvFo8zi255LcifKn5dZxM/nKyOUt5wExL//mWLo NBGQ== X-Gm-Message-State: AGi0PubJc58jDqSbuklcIxsmMXjLSXTSjgm1mBe+ms/16b77emxtQvay 5Gx3n3+eSmgpK6zo+XhGJb4oh7XwoqEkBzpDP14= X-Google-Smtp-Source: APiQypJkj3h4IbNgR4cMdKasaz8EhQwRIWrHOpGXnjlHwRSEI73O86rD70petjLsX3TQOkq0IuyqTxwmFzN2KzQW+3w= X-Received: by 2002:aca:c447:: with SMTP id u68mr17515332oif.17.1589136977697; Sun, 10 May 2020 11:56:17 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Date: Sun, 10 May 2020 15:56:06 -0300 Message-ID: To: Nikita Popov Cc: Ralph Schindler , PHP internals Content-Type: multipart/alternative; boundary="0000000000000e1f7805a54fc9f2" Subject: Re: [PHP-DEV] Proposal For Return-If / Early Return / Guard Clause Syntax From: david.proweb@gmail.com (David Rodrigues) --0000000000000e1f7805a54fc9f2 Content-Type: text/plain; charset="UTF-8" Suggestion: return if $x > 1; (to return "void") return $y if ($x > 1 && $x < 5); break if $x > 1; break 2 if $x > 1; throw new Exception if $x > 1; Em dom, 10 de mai de 2020 15:48, Nikita Popov escreveu: > On Sun, May 10, 2020 at 5:49 PM Ralph Schindler > wrote: > > > Hi! > > > > > > # Intro > > > > I am proposing what is a near completely syntactical addition (only > > change is to language.y) to the language. The best terminology for this > > syntax is are: `return if`, "return early", or "guard clauses". > > > > see: https://en.wikipedia.org/wiki/Guard_(computer_science) > > > > Over the past few years, I've seen a growing number of blog posts, > > conference talks, and even tooling (for example code complexity > > scoring), that suggest writing guard clauses is a good practice to > > utilize. I've also seen it more prevalent in code, and even attempts at > > achieving this with Exceptions (in an HTTP context) in a framework like > > Laravel. > > > > see abort_if/throw_if: > > https://laravel.com/docs/7.x/helpers#method-abort-if > > > > It is also worth mentioning that Ruby has similar features, and I > > believe they are heavily utilized: > > > > see: > > https://github.com/rubocop-hq/ruby-style-guide#no-nested-conditionals > > > > > > # Proposal > > > > In an effort to make it a first class feature of the language, and to > > make the control flow / guard clauses more visible when scanning code, I > > am proposing this in the syntax of adding `return if`. > > > > The chosen syntax is: > > > > return if ( if_expr ) [: optional_return_expression] ; > > > > As a contrived example: > > > > function divide($dividend, $divisor = null) { > > return if ($divisor === null || $divisor === 0); > > > > return $dividend / $divisor; > > } > > > > There is already a little discussion around the choice of order in the > > above statement, the main take-aways and (my) perceived benefits are: > > > > - it keeps the intent nearest the left rail of the code (in > > normal/common-ish coding standards) > > > > - it treats "return if" as a meta-keyword; if must follow return for > > the statement to be a guard clause. This also allows a person to more > > easily discern "returns" from "return ifs" more easily since there is > > not an arbitrary amount of code between them (for example if the return > > expression were after return but before if). > > > > - it has the quality that optional parts are towards the end > > > > - is also has the quality that the : return_expression; is very > > symmetrical to the way we demarcate the return type in method signatures > > "): return type {" for example. > > > > - has the quality of promoting single-line conditional returns > > > > > > # Finally > > > > One might say this is unnecessary syntactic sugar, which is definitely > > arguable. But we do have multiple ways of achieving this. > > > > Of course all of these things should be discussed, I think sub-votes > > (should this PR make it that far) could be considered. > > > > The PR is located here: > > > > https://github.com/php/php-src/pull/5552 > > > > As mentioned, some discussion is happening there as well. > > > > > > Thanks! > > Ralph Schindler > > > > > > PS: since implementing the ::class feature 8 years ago, the addition of > > the AST abstraction made this kind of syntactical change > > proof-of-concept so much easier, bravo! > > > > This proposal looks way too specific to me. I'm a big fan of returning > early -- but also of throwing early, breaking early and continuing early. > Supporting this just for returns seems odd / inconsistent to me. > > That said, I don't think this syntax solves a real problem in the first > place. If it solves a problem, it's mostly a problem of PHP coding styles > being a bit overzealous when it comes to formatting requirements for early > return/break/continue/throw. And that's not a problem that needs solving at > the language level... > > Regards, > Nikita > --0000000000000e1f7805a54fc9f2--