HI Stas, On Sun, Feb 10, 2019, 8:17 AM Stanislav Malyshev <smalys...@gmail.com wrote:
> Hi! > > > My thought that @ mainly relates to another RFC where errors/warning > > are very inconsistently reported or designed (like forcing one to use > > @). 8 would be a good candidate to clean that up, like the TypeError > > RFC. > > Cleaning up how PHP does errors would be awesome. After 20+ years of > organic growth without clear standards in this area, we've got a lot of > messy stuff happening there. But I don't think it can solve any > immediate issues - it's not likely that we'll replace every warning in > every extension overnight. You are right, long due. Also 8 is not immediate or overnight. However I think you are right as well in your other replies. While I wrote @ free code since years and I rarely see some in modern code, removing it may bring some BC issues that could delay 8 adoptions. It'd be nice if we found some model that > miraculously plugs into existing one and allows to improve things while > keeping everything working. If we get good new APIs - fine, but we'll > need @ to work with old APIs for a while. New APis would be amazing. We need a kind of miracle to agree on these new APIs but it will be really amazing to have new clear APIs. As far as I remember we have been there for 6/7 and failed to find a consensus. Resources and procedural APIs behaviors have survived a few attempts to kill them. I wish we could introduce some key ones with 8 and not barely focused in JIT and some basics cleanup :) By procedural behaviors, I mean all these functions based on the 90s designed C-like behaviors which are not fit anymore for today needs. best, Pierre
