Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:99867
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.128.174 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CANUQDCiEjr3NYr5ZXSnYZ9z1F_M9ftmPSwhKQ5xeuBDHSz=GUw@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> <CANUQDCiEjr3NYr5ZXSnYZ9z1F_M9ftmPSwhKQ5xeuBDHSz=GUw@mail.gmail.com>
Date: Thu, 13 Jul 2017 09:01:32 +0200
Message-ID: <CABdc3WouaFpLGnUihPgdCUR72M8_UE0z8EYSum2t7kQitUR6Rg@mail.gmail.com>
To: Niklas Keller <me@kelunik.com>
Cc: Mark Shust <mark@shust.com>, Rowan Collins <rowan.collins@gmail.com>, 
	PHP Internals List <internals@lists.php.net>, Aidan Woods <aidantwoods@gmail.com>
Content-Type: multipart/alternative; boundary="001a1146d954bf306705542d804f"
Subject: Re: [PHP-DEV] array coalesce operator concept
From: michal.brzuchalski@gmail.com (=?UTF-8?Q?Micha=C5=82_Brzuchalski?=)

--001a1146d954bf306705542d804f
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

2017-07-12 22:14 GMT+02:00 Niklas Keller <me@kelunik.com>:

> 2017-07-12 17:26 GMT+02:00 Micha=C5=82 Brzuchalski <
> michal.brzuchalski@gmail.com>:
>
>> 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
>> 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
>> hard
>> and leads to frustration.
>
>
> You have to update a whole lot of APIs before you can do that. There are
> many things where it's better to ignore the warning and check the return
> value and throw an exception if something is wrong.
>
> Regards, Niklas
>
>
Hi Niklas,

could you name few of them?
My ideal vision is catching thrown exceptions instead of suppressing errors=
.
BTW it would unlock '@' for future features like use for
annotations/attributes.

Regards,
--
Micha=C5=82 Brzuchalski

--001a1146d954bf306705542d804f--