Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:99850 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 43436 invoked from network); 12 Jul 2017 08:22:12 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 12 Jul 2017 08:22:12 -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.174 as permitted sender) X-PHP-List-Original-Sender: aidantwoods@gmail.com X-Host-Fingerprint: 209.85.128.174 mail-wr0-f174.google.com Received: from [209.85.128.174] ([209.85.128.174:34017] helo=mail-wr0-f174.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id E5/D3-01782-13CD5695 for ; Wed, 12 Jul 2017 04:22:11 -0400 Received: by mail-wr0-f174.google.com with SMTP id 77so23125914wrb.1 for ; Wed, 12 Jul 2017 01:22: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=G35AucRzVqob5WU41W8cTVai/AqzRigogtJ9XtEWGlo=; b=Ghv/W+vXf6lStT1Bl2a3hd2KYx8trNtFJyMog7E/PgToNAs/SYy13IeWNecC00wMWu PQoG4UpSydnWbL+NT/o46iuyz+TQUzMC8tc3sgIxpot5qICo5ux630km6U9uGwtcs9sn tgK1hsBEBcMUDv7egBM+8Vz6T2PmnGRvM/BY81OvBf97+QH/lW0mqRZ2S4B4dDyuRclc 83Y26m3Cn3SQkzuOeBffET579i7NBolE+BxbPkmq3VC+J/8nz7QHPB2owT0njAGRIWrt UX0OukrF5ccES1r27GoKsXskeZcGPux4pTUrYfw2WYyDWCbWQK19aqo6X16sP/AJVDAa T6qQ== 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=G35AucRzVqob5WU41W8cTVai/AqzRigogtJ9XtEWGlo=; b=gYyKDOOo5o3capbGZCbjFJ4vGlJ09OuE6p+UoXvp4qWZ7y3bQnv8m3AYBJNTXDIMDl QKZXP+CXGqmmpNHyv+QEVvscr8AKdhPuIUoGB+JCHlTxPcH5/F2H7eDocqR0jEYudWvO 9xvCk24sCDN5poxydS9ilAn71C1aICzBi1cf+DF/djovZekqDaxWp05Xn3lspHBxBw1p 0VI09o8w5yv7CnwDbHYw8dVEXUmxLAsVZUwSfYbHpmat1QcSVpRaCH6ZW9ABB+kcQHrb /9DANZocf/g8r0gpJMx72sE+uaw7Gaa4GdbE1d19JaGDt7mEMFqozxLMmD86QS3blKbx f7zA== X-Gm-Message-State: AIVw113h+ksbtJ+yLjEP7N7q8o75Zkh42QFbMp0zKv9ffNrg8OVCkMyV /UDm9YSUNZr921fOpuSS/V24XRsgFA== X-Received: by 10.28.49.7 with SMTP id x7mr1636846wmx.57.1499847726753; Wed, 12 Jul 2017 01:22:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.161.26 with HTTP; Wed, 12 Jul 2017 01:22:06 -0700 (PDT) In-Reply-To: References: Date: Wed, 12 Jul 2017 09:22:06 +0100 Message-ID: To: Mark Shust Cc: Rowan Collins , PHP internals Content-Type: multipart/alternative; boundary="001a1142e17ef86fcc05541a82ce" Subject: Re: [PHP-DEV] array coalesce operator concept From: aidantwoods@gmail.com (Aidan Woods) --001a1142e17ef86fcc05541a82ce Content-Type: text/plain; charset="UTF-8" In theory you'd only *need* it be considered a suppressor? PHP already exhibits the skipping behaviour (it only emits a warning for the wrong type used in `foreach`, skips the loop, and then continues with remaining code). No harm in/there is probably value in, making that skipping intent explicit in a RFC though, but in terms of a patch, the warning would only need be suppressed as far as I can tell? Another thing I meant to mention -- this should not only be useful for arrays, but for any `Traversable` too (i.e. it should suppress errors generated in using a type not compatible with being iterated over in a `foreach` loop, and not just if the type is not array). Kind regards, Aidan On 12 July 2017 at 02:50, Mark Shust wrote: > Aidan, > > Fantastic suggestion (@as) -- that is really the succinctness I was > initially looking for, and I think the intention makes a lot of sense. My > only concern/issue would be to make sure that isn't considered a > 'suppressor' -- but it's actual intent is to skip the execution of the > foreach to prevent the error/loop from occurring (rather than just > suppressing an error). > > Cheers, > Mark > > > On Tue, Jul 11, 2017 at 4:05 PM Aidan Woods wrote: > >> 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] >>> > >>> >> >> --001a1142e17ef86fcc05541a82ce--