Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:104449
MIME-Version: 1.0
References: <CAF+90c9E6O-12fKKY_kb5b_LvXgODbPpC73TNro+XpMewndT2Q@mail.gmail.com>
 <226B512C-02A7-4555-9288-D7A2DA89F068@benramsey.com>
In-Reply-To: <226B512C-02A7-4555-9288-D7A2DA89F068@benramsey.com>
Date: Sat, 16 Feb 2019 19:28:48 +0100
Message-ID: <CAEPJdunYik3MgTzUBeMuSkiqUA0LAMwULB65WB36G4UMdJmtaA@mail.gmail.com>
To: Ben Ramsey <ben@benramsey.com>
Cc: Nikita Popov <nikita.ppv@gmail.com>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000aac08605820710ee"
Subject: Re: [PHP-DEV] [RFC] Consistent type errors for internal functions
From: kontakt@beberlei.de (Benjamin Eberlei)

--000000000000aac08605820710ee
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Ben Ramsey <ben@benramsey.com> schrieb am Sa. 16. Feb. 2019 um 18:35:

> > On Feb 5, 2019, at 05:22, Nikita Popov <nikita.ppv@gmail.com> wrote:
> >
> > Hi internals,
> >
> > I'd like to bring forward the following proposal for PHP 8, which will
> make
> > (zpp) parameter parsing failures always result in a TypeError (rather
> than
> > generating a warning+null, depending on circumstances):
> >
> > https://wiki.php.net/rfc/consistent_type_errors
> >
> > The goal here is to remove one of the inconsistencies between
> user-defined
> > and internal functions, and to put us in a position where we can actual=
ly
> > start specifying type information in arginfo without fear of breaking
> > things.
>
>
> I like this RFC, and from a user perspective, this consistency is
> much-needed.
>
> While warnings don=E2=80=99t affect continued processing, uncaught TypeEr=
rors do.
> What is the recommended upgrade path for users? How will this affect the
> silence @-operator, since I=E2=80=99m sure many users use that to squelch=
 these
> warnings, and they accept the null or false return value as acceptable fo=
r
> processing the rest of the script.
>
> Cheers,
> Ben


This exception is only for argument errors. Fopen would continue to warn +
false when file doesnt exist, which is what @ is nostly used for (using
fopen as example)

>
>

--000000000000aac08605820710ee--