On Tue, Feb 5, 2019 at 5:17 PM Nikita Popov <nikita....@gmail.com> wrote:
> On Mon, Nov 26, 2018 at 10:42 PM Nikita Popov <nikita....@gmail.com> > wrote: > > > I'd like to move forward with this change. I think the overall reception > here has been positive, although in the discussion some other possibilities > that avoid/reduce the BC aspect have been discussed. I think now that we > have a PHP 8 branch, it would make sense to apply this as-is. The BC break > is quite minor (compared to the other changes in PHP 8) and I think this is > the cleanest way to solve the problem, as it only changes the list of > silences errors, without introducing any new error handling concepts or > mechanisms. I don't think that other changes that may or may not make it into PHP 8 should influence our decision - BC breaks accumulate and the more you have of them, the more difficult it is to migrate. I'm also present unaware of anything we already decided to 'break' in PHP 8 as of now (with the exception of the removal of deprecated 7.x features). That said - I think we all agree the BC breakage scope is small - but at the same time, it may be quite fatal for those that are affected. Those who have display_errors on (which is both horrible for production and at the same time fairly popular) are risking exposing sensitive data that beforehand, they were safely and explicitly hiding using @. Is there any reason *not* to do it in such a way that provides a gentler migration path? Introduce a new error level that would be a part of E_ALL in 7.4, but outside of E_ALL in 8.0 - that would govern whether fatal errors are silenced or not. Zeev
