Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:99860 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 81175 invoked from network); 12 Jul 2017 17:26:11 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 12 Jul 2017 17:26:11 -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.45 cause and error) X-PHP-List-Original-Sender: mark@shust.com X-Host-Fingerprint: 209.85.218.45 mail-oi0-f45.google.com Received: from [209.85.218.45] ([209.85.218.45:33314] helo=mail-oi0-f45.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id C6/88-01782-2BB56695 for ; Wed, 12 Jul 2017 13:26:11 -0400 Received: by mail-oi0-f45.google.com with SMTP id p188so25557229oia.0 for ; Wed, 12 Jul 2017 10:26:10 -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=krEJRdTfmBV7/OgT5sJQGQtA81oopRJEdMdVR8WjCDU=; b=gm6zlNOHYOL5T5UJIT6SSVI+xrhcqu6Bga7VUbYn+b4D/Knh1WKmOcoqg3Pz7cv/9t BIazuXvrJWNpeCNvYEgFrS3luaa2D5bVviEEmKcwFPnFaTNdaf2+UU/MMaRoAjHnGXrp sYpU/FPI/4xip5jJgvxMSw8Yw1LivopESHh5QkmB2OIMTLaKLQmH5wz3rqo9oLxJK9ei rpTBMvVHBOaAaUOOMabEwSwc8TcD9OK3Ou9irWvuaqwg4My4GDl+Rm/1GWaA4tbNTfl5 DwtKzI6LQo3hivVOHAZslVYYsCP7pVrdvrCCLpKyCefI9Pq3As0rmFXbDUmmXh3mD1Jt 8c6Q== 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=krEJRdTfmBV7/OgT5sJQGQtA81oopRJEdMdVR8WjCDU=; b=I0RDBwVYyw0pETd8hQuEQTOTe8iddnbSF75B3fhSFNCklI6av3nyEs8Kwgr+FhNtZ9 c7cNr0Lw5/53Y6S0Rgx1kmiDkhsmvnAFu40ajuxQEqy3NRbMCESABimRKVViu8oYo1PO F88zmVbfPuXMj4aGbtz5uh+EaLVZnKhYiRR/jwE2UnTsw8agtvxfjmvS5+uDLmVNiWnv uQPK1gXHCSbt1h4jJ1/leYy8CRUNLpXgdKlHugAdjPK2So8c/28Rgf+Oa7RrTfZV6evo rinAvvE9H7b+lIMtSJpFUvlom3QblNHbp9v9TkPZxRsGVKRp11L71VPR8vxfabA5gJmz Q1JA== X-Gm-Message-State: AIVw1119JPQ80JdwZnQ+UnXvBwAu0jQVvFYxDjHLvtIVeqk+XepNHVWl 3H4N0KwvqDm7PfFLbn4HM013jwjGbUnh X-Received: by 10.202.81.202 with SMTP id f193mr5093342oib.178.1499880367038; Wed, 12 Jul 2017 10:26:07 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Date: Wed, 12 Jul 2017 17:25:56 +0000 Message-ID: To: Aidan Woods , =?UTF-8?Q?Micha=C5=82_Brzuchalski?= Cc: Rowan Collins , PHP Internals List Content-Type: multipart/alternative; boundary="001a113d7f2c7bbba40554221c5b" Subject: Re: [PHP-DEV] array coalesce operator concept From: mark@shust.com (Mark Shust) --001a113d7f2c7bbba40554221c5b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I agree, error suppression is generally ugly/nasty behavior that is a hack to the language. I also agree that if it's there now, @as is a pretty good use for it. That said, another possibility I thought of is automatically converting whatever is passed into a foreach loop to be cast into an iterable/array for the duration of the loop. I'm wondering what opinions would be on the cons of going this route. Given php's weak typing and someone's desire to execute a foreach on _something_, I think this alternate method might be a good option. Mark On Wed, Jul 12, 2017 at 12:18 PM Aidan Woods wrote: > > IMHO the whole error supression and its operator should be deprecated > and removed from language. > > Supressing errors is just hiding problems because someone didn't want t= o > solve it. Supressing errors > > makes debuging very hard and leads to frustration. > > I can concur with disliking the error suppression operator, and in genera= l > silent failures. This is why we > have linting CI checkers though ;-) Tbh, I also dislike silent type > "juggling" for the same reason. But > those are my opinions, and they don't get on with everyone. > > Deprecation of the operator is probably a different discussion. Though to > say a few words on it: if > presented with no other option, I'd rather someone suppress an error in a > controlled single-use > manner, than changing the global error reporting setting somewhere in > their code to do the same > thing. > Notwithstanding my preference on error suppression method, I'd > still prefer it avoided if at all possible, > though again, very much IMO. > > Regardless of personal opinion on actually using the operator, would you > not rather it were used in all > cases of error suppression? > 'tis to say, if we are going to introduce new error suppression behaviour > (which is what the proposal > here does), should it not be consistent with existing language features? > > Given that the error suppression operator is a feature already in the > language, I think that it makes > sense to use it to facilitate this use case of "silently skip the loop if > it errors", as opposed to introducing > a new operator to do it. > > I think it makes sense to force its use to be as targeted as possible too= : > Placing the `@` on `as` is the most targeted placement for catching the > failure we're talking about (failing to > be able to iterate over something), as opposed to something like > `@foreach` which could feasibly mean > anything failing in the entire loop block. > > If we're going to introduce this behaviour, let's get it right ;-) (even > if we don't like it ourselves) > > Kind regards, > Aidan > > On 12 July 2017 at 16:26, Micha=C5=82 Brzuchalski > wrote: > >> 12.07.2017 15:35 "Mark Shust" napisa=C5=82(a): >> > >> > 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 @a= s >> > definition could be really useful. >> >> IMHO the whole error supression and its operator should be deprecated an= d >> removed from language. Supressing errors is just hiding problems because >> someone didn't want to solve it. Supressing errors makes debuging very h= ard >> and leads to frustration. >> >> > >> > 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 alrea= dy >> >> > > 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 f= or >> > > arrays, but for any `Traversable` too (i.e. it should suppress error= s >> > > 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 withi= n >> 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 bi= t >> 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 < >> rowan.collins@gmail.com> >> > >>>> wrote: >> > >>>> >> > >>>> > On 11 July 2017 16:02:18 BST, Mark Shust wrote= : >> > >>>> > >For a syntactic >> > >>>> > >sugar/improvement, this can be shorthand for executing the loo= p >> > >>>> instead >> > >>>> > >of >> > >>>> > >wrapping the block within an is_array check: >> > >>>> > > >> > >>>> > > >> > >>>> > >> > >>>> > > >> > >>>> > >$foo =3D "abc"; >> > >>>> > > >> > >>>> > >foreach (??$foo as $bar) { >> > >>>> > > >> > >>>> > > echo $bar; >> > >>>> > > >> > >>>> > >} >> > >>>> > >> > >>>> > Hi! >> > >>>> > >> > >>>> > I think there's definitely the start of a good idea here, but t= he >> > >>>> 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 $ba= r >> to >> > >>>> the >> > >>>> > scalar value, as would happen with (array)$foo >> > >>>> > >> > >>>> > The challenge, then, is to come up with some syntax that someho= w >> > >>>> 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] >> > >>>> > >> > >>>> >> > >>> >> > >>> >> > > >> >> > --001a113d7f2c7bbba40554221c5b--