On Thu, 6 Jun 2019 at 12:49, Arvids Godjuks <arvids.godj...@gmail.com> wrote:
> consistency, in general, would be a nice change of pace so you don't have > to keep in mind that there are slight differences in behaviour depending on > what you call - a built-in function or a userland one. > This is my view as well. Another thing that inconsistency causes problems with is polyfills - if you want to wrap, emulate, or otherwise reimplement an internal function, it can be fiddly to emulate the subtleties of ZPP. (This gets worse with objects, which can do all sorts of wacky things internally that have no user-space equivalent, but that's a topic for another day.) Would it be possible to use a combination of automation (analysis of the C code, or fuzz testing of the functions) and collaboration (a great big list people can work through a section of and report back) to categorise the functions in core? Something like: a) not affected, because handling is consistent with userland anyway b) should explicitly accept nulls c) should explicitly reject nulls We do however have to make a tricky judgement on functions in category c, of how much code is going to break if we make them stricter. Regards, -- Rowan Collins [IMSoP]
