Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:99844 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 6918 invoked from network); 11 Jul 2017 20:05:11 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 11 Jul 2017 20:05:11 -0000 Authentication-Results: pb1.pair.com header.from=aidantwoods@gmail.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=aidantwoods@gmail.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.128.171 as permitted sender) X-PHP-List-Original-Sender: aidantwoods@gmail.com X-Host-Fingerprint: 209.85.128.171 mail-wr0-f171.google.com Received: from [209.85.128.171] ([209.85.128.171:35969] helo=mail-wr0-f171.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 7D/70-01782-57F25695 for ; Tue, 11 Jul 2017 16:05:11 -0400 Received: by mail-wr0-f171.google.com with SMTP id c11so3869332wrc.3 for ; Tue, 11 Jul 2017 13:05:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=OerZGcn6Fv6HsUdqKOnugBoln3LMWBIxsJ574e+dtuY=; b=M/j0Eg+IpE/76lIAcjD2fsDdRs5gVdqmYHsbvoi46snXC7RgxiTVTeQobtfhCJt1k7 oQOadx2f6O8zs4kJO8Px/8hv4hkEUtgI7U19qsBt0KcJZG0bsbI0YH0D1GisIcJKCRoW 1EYE/+Y/sbe8+ND1ySVcxSqXU31ZWuOEmSH0nRcxZMwE6FqnWPxQWxVH87f6eb41//W8 +lhWmunxK59Ms2dF/f0wmnClP8IzDeJlbpl8xiLYcoxz73ziukFRpe0PcCGKWt3h3S+o sdkel+AnnFzVtC0mmBfx9ED+csOpt5M06CAm5xq6BM+hUq+gm8uHgo2p5mKUGKqj8eXp bMlA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=OerZGcn6Fv6HsUdqKOnugBoln3LMWBIxsJ574e+dtuY=; b=Xfem20JNflUo/GWOrxLa8bAvVQj9H8mSL6F2ZbFrAEBzJU4ZamFBJyerZ0LppgqK5S k+V2B1a5RqhOrJRMECL/SZzfbVXdRQShvp2VIUcqqzMN1g1uGVrbvUtOVHYO5A3TDQJ7 01GO11R+BFHSCmvAGNNP7D6xeMM0FiZdjA0yXJt3qPszRcvCW1kzmHxCXcg1oLvJ3+xR srmtmbVj3WaYGpx+965QT32FMYw20Z6jo2v0iOpGjhA1vMLgdKoQIXT4qpfn6A7t+Z0+ tco8ndzOtRf6TToLNomeG1FbPWFAetj4+RBFhIqGyf6DwocpGWX9RsFjxzDT1BS5vfVu QlKQ== X-Gm-Message-State: AIVw113Xyow6Z+/fDbw7Fs9K674r9RsMWeLCHJioojTnofXQ8RdlWF7G 52L2wNd4KAFSA8Vs+rKXIxANjSki4A== X-Received: by 10.223.160.174 with SMTP id m43mr851710wrm.194.1499803507190; Tue, 11 Jul 2017 13:05:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.161.26 with HTTP; Tue, 11 Jul 2017 13:05:06 -0700 (PDT) In-Reply-To: References: Date: Tue, 11 Jul 2017 21:05:06 +0100 Message-ID: To: Mark Shust Cc: Rowan Collins , PHP internals Content-Type: multipart/alternative; boundary="001a114b56d64775df05541037b4" Subject: Re: [PHP-DEV] array coalesce operator concept From: aidantwoods@gmail.com (Aidan Woods) --001a114b56d64775df05541037b4 Content-Type: text/plain; charset="UTF-8" If you were willing to accept ``` foreach ($foo as $bar) if (is_array) { ... } ``` as a solution, then you might as well use ``` if (is_array($foo)) foreach ($foo as $bar) { ... } ``` I wonder if this could be better achieved by expanding what the error suppression operator `@` can do? This entire behaviour seems more like an error suppression action on `foreach` to me, otherwise should we consider coalescing operators for other types/creating a more generic one? Going back to the error suppression operator: e.g. perhaps ``` foreach ($foo @as $bar) { ... } ``` could prevent skip past execution of the entire foreach block if there is an error using $foo as an array. So might make most sense to place the `@` on `as`, IMO, but I guess arguments could be made to place it like `@foreach ($foo as $bar)` or `foreach @($foo as $bar)`. Regards, Aidan On 11 July 2017 at 20:06, Mark Shust wrote: > Thanks for the great feedback. > > Based on the last mindset on keyword syntax, this comes to mind, intended > to be used similarly to the 'use' keyword when used within the context of a > closure: > > foreach ($foo as $bar) if (is_array) { > ... > } > > > I don't think this is a vast improvement over wrapping this within an > is_array check, however it does avoid the additional nest/wrapping. I was > hoping for something that reads a bit more concisely or with a bit more > syntactical sugar than the above. I think this does read nicely though. > > Cheers, > Mark > > On Tue, Jul 11, 2017 at 1:50 PM Rowan Collins > wrote: > > > On 11 July 2017 16:02:18 BST, Mark Shust wrote: > > >For a syntactic > > >sugar/improvement, this can be shorthand for executing the loop instead > > >of > > >wrapping the block within an is_array check: > > > > > > > > > > > > > >$foo = "abc"; > > > > > >foreach (??$foo as $bar) { > > > > > > echo $bar; > > > > > >} > > > > Hi! > > > > I think there's definitely the start of a good idea here, but the syntax > > you suggest doesn't read quite right. As has been pointed out, this > differs > > from existing features in two ways: > > > > - the special handling is for any non-iterable value, not just null or > > empty/falsey values, for which you could use $foo??[] and $foo?:[] > > respectively > > - the handling is to skip the loop, not loop once assigning $bar to the > > scalar value, as would happen with (array)$foo > > > > The challenge, then, is to come up with some syntax that somehow suggests > > these rules. The "??" is too much like the null coalesce, which would be > > misleading. > > > > The only idea that immediately comes to mind is a keyword: > > > > foreach ifarray ($foo as $bar) { > > > > I can't say I'm that keen on that syntax, but maybe it will inspire > > someone else. > > > > Regards, > > > > -- > > Rowan Collins > > [IMSoP] > > > --001a114b56d64775df05541037b4--