Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:77394
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.176 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <1A5B2D07-FEC6-410E-85C9-3FBE2F105104@golemon.com>
References: <CAPwsocHm4wme7TDX-1hp=PdNGi0KzAwRz4RezW3KddV9_4m=JQ@mail.gmail.com>
	<1A5B2D07-FEC6-410E-85C9-3FBE2F105104@golemon.com>
Date: Sat, 20 Sep 2014 23:06:24 +0100
Message-ID: <CAPwsocEEQEGpUs6yCJWa3q1TrjsNsEbpmtMt0OjuCXZSx72-Jw@mail.gmail.com>
To: Sara Golemon <php@golemon.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] [RFC] Loop... or...
From: leight@gmail.com (Leigh)

On 20 September 2014 20:47, Sara Golemon <php@golemon.com> wrote:
>
> I like the general idea, but rather than explicitly focusing on the 'or' keyword, how about just giving all loop constructs (do/while/for/foreach) a return value?  I'd suggest an integer return value indicating the number of times the loop executed.
>
> This accomodates your use case since foreach(...) {} or { defaultblock } still works, while also allowing for others:
>
> e.g.:
> $ranTwice = foreach(...) {} == 2;
>
> It does introduce a temp var, but OpCache+ can trivially optimize that out when it isn't used.
>
> -Sara

Sorry @Sara - didn't reply to all the first time.

----

mind === blown

This would open up a huge amount of other functionality I'd never
dreamed of (some of which is quite scary!)

for($i = for(...) {}; $i < ...) {}

I'm really not sure I understand the full implication of this though.
This would mean changing loop constructs from statements to
expressions. I wonder how difficult that will actually be, and what
other problems it would cause (I obviously haven't played with this
idea yet).

It would also mean having to make { default block } into an
expression... with a return value (to be allowed on either side of the
boolean or)

Lots to think about here, if it's at all viable this will need it's
own separate RFC, it's a much more invasive change, but definitely a
great idea.