On Thu, Jul 13, 2017 at 2:55 AM, Tony Marston
wrote:
> "David Rodrigues" wrote in message news:CAEsg9X2ECG62i7Z_Nu11kqr7
> yvbkmucd3mxgt78ulampfx-...@mail.gmail.com...
>
>>
>> The idea is good, but I don't know if it is more clear than an 'if()'
>>
>
> I think that this proposal is totally ridic
"David Rodrigues" wrote in message
news:caesg9x2ecg62i7z_nu11kqr7yvbkmucd3mxgt78ulampfx-...@mail.gmail.com...
The idea is good, but I don't know if it is more clear than an 'if()'
I think that this proposal is totally ridiculous and should be shot down in
flames. My reasoning is as follows:
>
> 2017-07-12 22:14 GMT+02:00 Niklas Keller :
>
> > 2017-07-12 17:26 GMT+02:00 Michał Brzuchalski <
> > michal.brzuchal...@gmail.com>:
> >
> >> 12.07.2017 15:35 "Mark Shust" napisał(a):
> >> >
> >> > Hi Aidan,
> >> >
> >> > I think you are correct on all points. The initial emit is just a
> >> wa
2017-07-12 22:14 GMT+02:00 Niklas Keller :
> 2017-07-12 17:26 GMT+02:00 Michał Brzuchalski <
> michal.brzuchal...@gmail.com>:
>
>> 12.07.2017 15:35 "Mark Shust" napisał(a):
>> >
>> > Hi Aidan,
>> >
>> > I think you are correct on all points. The initial emit is just a
>> warning,
>> > so I think
2017-07-12 17:26 GMT+02:00 Michał Brzuchalski
:
> 12.07.2017 15:35 "Mark Shust" 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 tr
Stas,
Wow, for some reason it didn't occur to me to try that. Confirming the
following works:
foreach ($foo ?? [] as $bar) {
echo $bar;
}
I think the biggest need for this is if the value is null. Guess it's
case-closed :)
Might be a good idea to add this to the docs, pretty neat.
Mark
Hi!
> Code will error if a non-array value is passed through a looping feature.
> For example, this code:
>
>
> $foo = "abc";
>
> foreach ($foo as $bar) {
Looks like $foo??[] would work here. If $foo is something like false or
null, that is. If it's not, this is probably a serious bug (why wo
> 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
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 iterab
> 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 suppr
> 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).
Yes, a warning is not an error. If someone dont care about warnings from
error prone code, set the error_reporting accordingly
12.07.2017 15:35 "Mark Shust" 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 i
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
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
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 pr
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 ent
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
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 s
Hello :-),
Thank you for the proposal. I have a question though: How is it
different from:
* `foreach ($foo ?: [] as $bar) { … }` if `$foo` does not exist,
* `foreach ((array) $foo as $bar) { … }` if `$foo` is not an array.
I understand your issue, but you can probably type your data with
`
The idea is good, but I don't know if it is more clear than an 'if()'
Em 11 de jul de 2017 12:15 PM, "Mark Shust" escreveu:
> Hello,
>
> I wanted to garnish feedback on a RFC proposal. This is just a concept at
> this point, and is inspired by the null coalesce operator.
>
> Code will error if a
20 matches
Mail list logo
