On Tue, 1 Mar 2022 at 10:43, Christoph M. Becker <cmbecke...@gmx.de> wrote:
> I said, the BC break doesn't appear to be *that* serious. > It is when it's a Fatal Error, and there are lots of them :-) > To elaborate: in my opinion, it is a good thing if internal functions > and userland functions behave the same regarding parameter types. Yes, agreed. However, picking *some* functions and make *some* of their parameters > nullable does not look reasonable to me. Also agreed... while I did start with that suggestion, I'm uncomfortable with making some parameters nullable due to how it would affect those using `strict_types` (where it can be a good check for some oddities). Since it has been brought up multiple times that it is hard to find all > occurrences which would have to be adapted, I suggested a somewhat > viable solution for userland code (namely to define userland functions > which establish the old behavior; and of course, you'd need some tooling > to replace the original function calls). But that's a lot of work, and creates even messier code... I'm pretty confident the best solution is to keep all parameter types the same (I could argue that some parameters could do with a "cannot be empty" exception, to reject NULL and an Empty String, but that would be a different RFC)... and anyone using `strict_types` will still have a Type Error when they pass a value of the wrong type to these parameters... the *only* change is for those not using `strict_types`, for NULL to still be coerced to a string/int/float/bool, as it always has been for internal functions... and I think this can be done to user functions as well, as developers not using strict_types won't have cared about this before. Craig
