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 <aidantwo...@gmail.com> 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 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ł Brzuchalski <michal.brzuchal...@gmail.com
> > wrote:
>
>> 12.07.2017 15:35 "Mark Shust" <m...@shust.com> napisał(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 @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 hard
>> and leads to frustration.
>>
>> >
>> > Cheers,
>> > Mark
>> >
>> > On Wed, Jul 12, 2017 at 4:22 AM Aidan Woods <aidantwo...@gmail.com>
>> 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 <m...@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
>> 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 <aidantwo...@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
>> 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 <m...@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.coll...@gmail.com>
>> > >>>> wrote:
>> > >>>>
>> > >>>> > On 11 July 2017 16:02:18 BST, Mark Shust <m...@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 = "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]
>> > >>>> >
>> > >>>>
>> > >>>
>> > >>>
>> > >
>>
>>
>
