Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:99856 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 63835 invoked from network); 12 Jul 2017 13:34:31 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 12 Jul 2017 13:34:31 -0000 Authentication-Results: pb1.pair.com smtp.mail=mark@shust.com; spf=permerror; sender-id=unknown Authentication-Results: pb1.pair.com header.from=mark@shust.com; sender-id=unknown Received-SPF: error (pb1.pair.com: domain shust.com from 209.85.218.53 cause and error) X-PHP-List-Original-Sender: mark@shust.com X-Host-Fingerprint: 209.85.218.53 mail-oi0-f53.google.com Received: from [209.85.218.53] ([209.85.218.53:34741] helo=mail-oi0-f53.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id F7/36-01782-C5526695 for ; Wed, 12 Jul 2017 09:34:31 -0400 Received: by mail-oi0-f53.google.com with SMTP id l130so19519798oib.1 for ; Wed, 12 Jul 2017 06:34:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=shust-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=BNswDwwYLomrrx1VIgeEg507kJ+hHamTc4zeqUQul58=; b=XiBexsrBBSqzFVHjkmB29FQKAgRGyMIlgzGAqacMEASJA8WwZQ8gryCutcaCdoExvm 8pd6+Ti0OxMYaQfn2o420uLa8idsTZ0Su7dNi1AVj/dB6gJagWd8GFugw48UqAvxgtLc VjRIGvbdg/kdeR7AJM+8Y8M4b8P6pwCrIPenqEuflw23NcbVFeTj76gOYbqwwduzhmLz mb538SC3B3Ogka9/915p8Fv6bidUuZJpzg/ko7QJpSq2oxrqwkWAZ45CyH77yhPT9hx3 MY1p7gxy1NQ3YLNgxhSRoc620KKW48czUX8RrFty/sGFZaqaxdUN8EAEWR2X5zzg4KuY Xo1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=BNswDwwYLomrrx1VIgeEg507kJ+hHamTc4zeqUQul58=; b=XDpslsu9jE32X9YwIGhCnImbvMJhjyCqZRVSCsHknsS6waw1anixZu3m2kqgxtnTLC B/ewbR3lv4fMbCwvbIkUCZZHiHuiwRJvSz2B8SH0SerwxD4VMpXFqpYshWhI08kI/jcs Or1m+att61Bx0eUJPHHelhvcubOo0Zvn/FGj1cSwOzWKJOOs1yUspJc5mPAzKkZcvQq3 F9U5yZD2M4Mrl8WxEpIukmA3PwsI4JdV3rJjCXXK6sOHeXXV8a/72TWWidu4NhC/W+Ps 6TxOt43yWdZdTCgjd6GurNrdoPDvtPji5UYvgg2YSRDNTGsR5ZjQgBLCnTyWP+R4abCK XpzA== X-Gm-Message-State: AIVw110lObUFUTTnuG5W7WthuSZJaAOmIzoN7JULroYfe6Qw+7u0GHUF 4RdIpeZCFOABfB7HIQTJEz3Po929ce79 X-Received: by 10.202.106.6 with SMTP id f6mr3974823oic.85.1499866457705; Wed, 12 Jul 2017 06:34:17 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Date: Wed, 12 Jul 2017 13:34:06 +0000 Message-ID: To: Aidan Woods Cc: Rowan Collins , PHP internals Content-Type: multipart/alternative; boundary="001a1141b11a6c3b0605541edf49" Subject: Re: [PHP-DEV] array coalesce operator concept From: mark@shust.com (Mark Shust) --001a1141b11a6c3b0605541edf49 Content-Type: text/plain; charset="UTF-8" Hi Aidan, I think you are correct on all points. The initial emit is just a warning, so I think a suppressor will work just fine, since it does just pass over the foreach if a traversable isn't passed in. I could see this being helpful as it makes wrapping an if block around a foreach not needed anymore (and in turn indenting the foreach another level), replacing it with just a single character. I also think for those that use linting tools and flag error suppressions, that an @as definition could be easily ignored from such a linter. I develop with warnings on, and see error suppressions as a sort of code smell, however I think the @as definition could be really useful. Cheers, Mark On Wed, Jul 12, 2017 at 4:22 AM Aidan Woods wrote: > 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] >>>> > >>>> >>> >>> > --001a1141b11a6c3b0605541edf49--