On Thu, 6 Jun 2019 at 12:49, Arvids Godjuks email@example.com>
> 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
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?
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.