Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:99868
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain kelunik.com from 81.169.146.221 cause and error)
MIME-Version: 1.0
In-Reply-To: <CABdc3WouaFpLGnUihPgdCUR72M8_UE0z8EYSum2t7kQitUR6Rg@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> <CABdc3WouaFpLGnUihPgdCUR72M8_UE0z8EYSum2t7kQitUR6Rg@mail.gmail.com>
Date: Thu, 13 Jul 2017 09:35:00 +0200
Message-ID: <CANUQDCiwrR=qZ_-w1zsGG1QgnUzZSeZqkMOWkrBTkJ6K98VkPg@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>, Aidan Woods <aidantwoods@gmail.com>
Content-Type: multipart/alternative; boundary="001a1137be7869e2f305542df8f9"
Subject: Re: [PHP-DEV] array coalesce operator concept
From: me@kelunik.com (Niklas Keller)

--001a1137be7869e2f305542df8f9
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 anothe=
r
> >> > 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 becau=
se
> >> 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 ar=
e
> > many things where it's better to ignore the warning and check the retur=
n
> > value and throw an exception if something is wrong.
> >
> > Regards, Niklas
> >
> >
> Hi Niklas,
>
> could you name few of them?
>

Sure.

fwrite and many other stream functions -
https://github.com/amphp/byte-stream/blob/47775086376fd2f82fc70b3862aa82e64=
a5ea667/lib/ResourceOutputStream.php#L67

openssl_x509_read -
https://github.com/kelunik/certificate/blob/524fa432ed1b5f50efbe7749f3c19e2=
8a9866bc7/lib/Certificate.php#L13


> My ideal vision is catching thrown exceptions instead of suppressing
> errors.
> BTW it would unlock '@' for future features like use for
> annotations/attributes.
>

We would have to make it a compile time error for quite a long time before
we could reuse any operators.

Regards, Niklas

--001a1137be7869e2f305542df8f9--