I just think that this way is more compatible witth the reading. "Return X
if Y" seems better than "return (if) X: (then) Y". Too the ":" could
conflicts with return type.
Em dom, 10 de mai de 2020 16:59, Ralph Schindler
escreveu:
>
>
> On 5/10/20 1:56 PM, David Rodrigues wrote:
> > Suggestion:
Hi Ralph,
Like others, I think this feels too narrow in its scope, and doesn't add
enough over existing syntax.
You mention that Ruby has a similar feature, but there it's not a
special syntax for guard clauses per se, but a "modifier" form of the if
statement:
Benas,
> On May 10, 2020, at 15:19, Benas IML wrote:
>
> Hello,
>
> I think that we SHOULD not introduce a new keyword (e. g. guard) since that
> would be a "major major" backwards incompatibility. "Guard" is a really
> generic
> word and a great example of that is Laravel and their
On 5/10/20 1:56 PM, David Rodrigues wrote:
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;
100% that will/should be a votable alternative option should this get to
the voting phase.
I
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
Hello,
I think that we SHOULD not introduce a new keyword (e. g. guard) since that
would be a "major major" backwards incompatibility. "Guard" is a really
generic
word and a great example of that is Laravel and their authentication guards.
In general, I don't think that early returns require a
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!
> >
> >
> > #
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".
>
>
Am 10.05.20 um 18:26 schrieb John Bafford:
Hi Ralph,
On May 10, 2020, at 11:49, 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`,
On Sun, 10 May 2020 at 17:49, 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:
Hi Ralph,
> On May 10, 2020, at 11:49, 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
On 28.04.2020 at 21:03, Benjamin Eberlei wrote:
> Hey,
>
> while working on cleanups for the internal error handling code,
> specifically extracting different rendering logic into pluggable hooks (
> https://github.com/php/php-src/pull/5484) I came across the ini settings
> "xmlrpc_errors" and
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
Maybe throw an exception by default when it happen. Considering
max_input_vars+1, when hit, throw.
Em dom, 10 de mai de 2020 09:34, Craig Duncan escreveu:
> >
> > Although not particularly elegant, and it does require you to reject
> requests that hit but don't exceed the limit, I've used this
>
> Although not particularly elegant, and it does require you to reject
requests that hit but don't exceed the limit, I've used this approach
before:
$max = ini_get("max_input_vars") - 1;
$check = count($_REQUEST);
if ($check > $max) {
throw new RequestException("Request is too large, only
I've moved https://wiki.php.net/rfc/non-capturing_catches to voting. Please
state your opinions. This vote will will end on 2020-05-24 at 9:00 UTC.
--
Best regards,
Max Semenik
16 matches
Mail list logo
