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]
> >>>> >
> >>>>
> >>>
> >>>
> >
