Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:110115
To: Nikita Popov <nikita.ppv@gmail.com>
Cc: PHP internals <internals@lists.php.net>
References: <f9109d72-f3d3-5b12-16bb-9ec03d164cf4@ralphschindler.com>
 <CAF+90c8CbXYumgz1Jzujo0u9wOeX_qxaizAMDykCztZ=ChZ7_g@mail.gmail.com>
Message-ID: <46f3153a-5c35-398e-3a87-437d84afa884@ralphschindler.com>
Date: Sun, 10 May 2020 14:50:51 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0)
 Gecko/20100101 Thunderbird/68.8.0
MIME-Version: 1.0
In-Reply-To: <CAF+90c8CbXYumgz1Jzujo0u9wOeX_qxaizAMDykCztZ=ChZ7_g@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Proposal For Return-If / Early Return / Guard Clause
 Syntax
From: ralph@ralphschindler.com (Ralph Schindler)


> 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.

I agree with this sentiment, and I'll update the PR accordingly and this 
will be reflected when I make the RFC itself.

(Throw feels different as its parameter is not optional and is always a 
complex type, and is in a different area of the parser... But I'll look 
more deeply at adding that soon.)

> 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...

I think we could say the same thing about most new additions: fn arrow 
functions, str_starts_with/str_ends_with, trailing comma in lists & 
function calls, str_contains(), flexible (indented) heredocs, list 
reference assignment, native de-structuring.. just to name a few that 
all fit into the same kind of quality of life category. Nearly all of 
those were achievable via some kind of syntax before their addition, but 
I think we can agree we're better off having them, than not- even if one 
chooses not to use them.

Having been programming with PHP for 22+ years now, and making it a 
point to evolve my tastes/preferences with the changing language and 
whatever the prevalent practices are in the community (and other 
languages), my desire for including these quality of life improvements 
remains quite high as it keeps the language interesting and competitive.

Put another way, as someone who's come to really appreciate the 
aesthetics and clarity of intent of code,.. and having seen this is some 
places in the wild already I feel are successful, I personally feel its 
a good thing to perhaps to run through the RFC process for inclusion in 8.

Thanks!
Ralph Schindler