Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:99859
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.128.169 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CABdc3WrHjLXpiCto+zvxBQv7bN6K+=c2zwE-a4YL=pYrHtANDg@mail.gmail.com>
References: <CAOe2Xe4j9dOa63wkG2gJxosH1fymWDB9C-zcXwDWGcB=Zw9w9g@mail.gmail.com>
 <E29279E7-D813-437B-BECB-E2612A6C86DE@gmail.com> <CAOe2Xe6vY2byZg0MSru=HftqBSwW_B_SsseN8L=pVi39LCccBA@mail.gmail.com>
 <CALtMV+NeLjPfdhGhW4idn9O-t+ZnPGwsXraeVWNW6qzNadRKVw@mail.gmail.com>
 <CAOe2Xe6B5QxV6Mwo5tNAoCLdbcw8WsXHa_i-bPrYoZYhsEY6Gw@mail.gmail.com>
 <CALtMV+OB9_u1R8tZhmsTbj7W9HYZQ1dNMEAP5ajHwQdGZaFi1w@mail.gmail.com>
 <CAOe2Xe7JpeHNWYDB-BBRDNhmNA7r3czc567JuFprcZ0ZhCvvBw@mail.gmail.com>
 <CABdc3WpNxYKGfgL8BP_8MaJgLm_dkDjHkkcuEf34JYV4S4NDJQ@mail.gmail.com> <CABdc3WrHjLXpiCto+zvxBQv7bN6K+=c2zwE-a4YL=pYrHtANDg@mail.gmail.com>
Date: Wed, 12 Jul 2017 17:18:01 +0100
Message-ID: <CALtMV+Nb5FHSH=yhx3R=2fPWmcN06BjCHind38fy4bL8Yoh8BA@mail.gmail.com>
To: =?UTF-8?Q?Micha=C5=82_Brzuchalski?= <michal.brzuchalski@gmail.com>
Cc: Mark Shust <mark@shust.com>, Rowan Collins <rowan.collins@gmail.com>, 
	PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="001a1142e17e031bdc05542129af"
Subject: Re: [PHP-DEV] array coalesce operator concept
From: aidantwoods@gmail.com (Aidan Woods)

--001a1142e17e031bdc05542129af
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

> 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 to
solve it. Supressing errors
> makes debuging very hard and leads to frustration.

I can concur with disliking the error suppression operator, and in general
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 <michal.brzuchalski@gmail=
.com>
wrote:

> 12.07.2017 15:35 "Mark Shust" <mark@shust.com> 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 ov=
er
> > 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 tho=
se
> > 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.
>
> 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 to solve it. Supressing errors makes debuging very ha=
rd
> and leads to frustration.
>
> >
> > Cheers,
> > Mark
> >
> > On Wed, Jul 12, 2017 at 4:22 AM Aidan Woods <aidantwoods@gmail.com>
> wrote:
> >
> > > In theory you'd only *need* it be considered a suppressor? PHP alread=
y
>
> > > exhibits the skipping behaviour (it only emits a warning for the wron=
g
> 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 fo=
r
> > > 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 <mark@shust.com> 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 t=
he
> > >> 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 <aidantwoods@gmail.com>
> > >> 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 err=
or
> > >>> 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 <mark@shust.com> 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 <
> rowan.collins@gmail.com>
> > >>>> wrote:
> > >>>>
> > >>>> > On 11 July 2017 16:02:18 BST, Mark Shust <mark@shust.com> wrote:
> > >>>> > >For a syntactic
> > >>>> > >sugar/improvement, this can be shorthand for executing the loop
> > >>>> instead
> > >>>> > >of
> > >>>> > >wrapping the block within an is_array check:
> > >>>> > >
> > >>>> > >
> > >>>> > ><?php
> > >>>> > >
> > >>>> > >$foo =3D "abc";
> > >>>> > >
> > >>>> > >foreach (??$foo as $bar) {
> > >>>> > >
> > >>>> > >  echo $bar;
> > >>>> > >
> > >>>> > >}
> > >>>> >
> > >>>> > Hi!
> > >>>> >
> > >>>> > I think there's definitely the start of a good idea here, but th=
e
> > >>>> 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]
> > >>>> >
> > >>>>
> > >>>
> > >>>
> > >
>
>

--001a1142e17e031bdc05542129af--