Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:77398
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: softfail (pb1.pair.com: domain golemon.com does not designate 209.85.192.181 as permitted sender)
MIME-Version: 1.0
Sender: php@golemon.com
In-Reply-To: <CAPwsocGz4wGP8xQ0jy4dK5tRqt1Y9opbYTKefpE0ssmSXeKo2w@mail.gmail.com>
References: <CAPwsocHm4wme7TDX-1hp=PdNGi0KzAwRz4RezW3KddV9_4m=JQ@mail.gmail.com>
	<1A5B2D07-FEC6-410E-85C9-3FBE2F105104@golemon.com>
	<CAPwsocGz4wGP8xQ0jy4dK5tRqt1Y9opbYTKefpE0ssmSXeKo2w@mail.gmail.com>
Date: Sat, 20 Sep 2014 17:21:58 -0700
Message-ID: <CAESVnVp4M1vNjY+N-RZ9b1LqviDr0L11yXpBjMYdjc4xp42TWQ@mail.gmail.com>
To: Leigh <leight@gmail.com>, PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] [RFC] Loop... or...
From: pollita@php.net (Sara Golemon)

On Sat, Sep 20, 2014 at 3:03 PM, Leigh <leight@gmail.com> wrote:
> 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.
>>
>
> 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 < ...) {}
>
Yikes, I truly hope nobody ever writes that code.  Ever.

> 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).
>
I admit, I haven't thought it through entirely either.  Nor even if
it's definitely possible.

> 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)
>
Excellent point, a block only works with T_OR if it has a value.  I'm
pretty sure that at this point, it doesn't.  That does put a monkey
wrench into it.  Perhaps a lambda could accommodate that?  Starts to
get ugly though...

> 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.
>
Yeah, I might be trying too hard. Worth exploring a tiny bit though...

-Sara