Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:77450
Return-Path: <mike.php.net@gmail.com>
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Delivered-To: mailing list internals@lists.php.net
Received: (qmail 23155 invoked from network); 22 Sep 2014 10:16:05 -0000
Received: from unknown (HELO lists.php.net) (127.0.0.1)
  by localhost with SMTP; 22 Sep 2014 10:16:05 -0000
Authentication-Results: pb1.pair.com header.from=mike.php.net@gmail.com; sender-id=pass
Authentication-Results: pb1.pair.com smtp.mail=mike.php.net@gmail.com; spf=pass; sender-id=pass
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.49 as permitted sender)
X-PHP-List-Original-Sender: mike.php.net@gmail.com
X-Host-Fingerprint: 74.125.82.49 mail-wg0-f49.google.com  
Received: from [74.125.82.49] ([74.125.82.49:54108] helo=mail-wg0-f49.google.com)
	by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP
	id B8/E4-33885-2E6FF145 for <internals@lists.php.net>; Mon, 22 Sep 2014 06:16:04 -0400
Received: by mail-wg0-f49.google.com with SMTP id x12so2412549wgg.20
        for <internals@lists.php.net>; Mon, 22 Sep 2014 03:16:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20120113;
        h=sender:message-id:date:from:user-agent:mime-version:to:subject
         :references:in-reply-to:content-type:content-transfer-encoding;
        bh=IabNHoSsGMMVcF1kIU2xyNH8TgpYQC2XC4VMSH74JNQ=;
        b=zWK6C+ZF1sASurpIzvjjIQydDpoSBcOuKv9jCCyOoGj145jZwmb1JBEwxGJq71Xetw
         4Q3or5KW+XtCWQdqCJ6ALUep0JLBPHpgB11HqkN3+WPuNO6NI69GOcXaWP+33SsT57wr
         Non0uXCoYJdIQw2GrZojV5lgUrbhW5qDh2rIVcA1cfW0u3o0oq5oeZpDiaIRQjbrQvb0
         XAxh+btypmGeJVaMkqu+7a0t3VEgGoh6KlUxNnpWyXnrtLpYuLBn27D+e/mPSE0xbSdF
         k//MsgzyN7acWqxSB8n41DyunJ0FAJOnkxBkTTG02B1MN1HOWXi2la9z0ugZUvYNyuan
         z1Nw==
X-Received: by 10.180.94.163 with SMTP id dd3mr14256539wib.31.1411380960118;
        Mon, 22 Sep 2014 03:16:00 -0700 (PDT)
Received: from [192.168.4.120] (178-18-170-101.customer.bnet.at. [178.18.170.101])
        by mx.google.com with ESMTPSA id q3sm11541200wia.14.2014.09.22.03.15.59
        for <multiple recipients>
        (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
        Mon, 22 Sep 2014 03:15:59 -0700 (PDT)
Sender: Michael Wallner <mike.php.net@gmail.com>
Message-ID: <541FF6DE.5060904@php.net>
Date: Mon, 22 Sep 2014 12:15:58 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.0
MIME-Version: 1.0
To: Sara Golemon <pollita@php.net>, Leigh <leight@gmail.com>, 
 PHP internals <internals@lists.php.net>
References: <CAPwsocHm4wme7TDX-1hp=PdNGi0KzAwRz4RezW3KddV9_4m=JQ@mail.gmail.com>	<1A5B2D07-FEC6-410E-85C9-3FBE2F105104@golemon.com>	<CAPwsocGz4wGP8xQ0jy4dK5tRqt1Y9opbYTKefpE0ssmSXeKo2w@mail.gmail.com> <CAESVnVp4M1vNjY+N-RZ9b1LqviDr0L11yXpBjMYdjc4xp42TWQ@mail.gmail.com>
In-Reply-To: <CAESVnVp4M1vNjY+N-RZ9b1LqviDr0L11yXpBjMYdjc4xp42TWQ@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] Loop... or...
From: mike@php.net (Michael Wallner)

On 2014-09-21 02:21, Sara Golemon wrote:
> 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
> 

Actually, I once or twice wanted to use while() {} else {} instead of
wrapping the loop in an "if". The extended version of Sara, while
looking great at a first glance, quickly turns into a crazy nightmare
after looking at the points already cooked up :)

-- 
Regards,
Mike