On Wed, 2 Mar 2022 at 21:42, Alexandru Pătrănescu <dreal...@gmail.com> wrote:
> What bothers me a bit is why should strlen(false) be a valid method call > but strlen(null) not so much. I think this is the inconsistency that should > be fixed so the language would be easier to work with. > Hi Alexandru, I typically spend an hour carefully thinking about each email I send, both on and off list. I read and re-read what each person said, I try to understand why they are saying it, my replies / suggestions are me trying to find the best solution that will work for as many people as possible, and the consequences they would have. I do not consider my coding style to be only one, and I would never simply force someone to work in a different way, in the same way that I won't force a CSP scrpt-src that blocked 'unsafe-inline' on everyone no matter how many XSS vulnerabilities it would solve (I highlight provable problems, I make suggestions on how to fix, and I'm open to alternative ideas). With this RFC, I made my original suggestion, which was to alter some functions so they could continue to accept NULL. I was wrong with that approach (first I suggested doing this silently, which Larry correctly pointed out was too messy; then I considered Larry's idea of updating function signatures, but there are too many, and would reduce some useful checks for those using `strict_types`). The solution I have been proposing for the last week or so is based on making PHP work with the well documented and understood coercion behaviour for null, in a way that keeps with the spirit of the original RFC, and is how many PHP scripts work today (noting that your typical PHP developer does not dare enter the Internals mailing list). I respect your idea, but what you are suggesting is very messy, it seems to randomly deprecate and remove some type coercions, but that is just going to confuse developers, and make upgrading harder to 9.0 even harder than what is currently planned (see Python 2 to 3 as a classic example). I know some people here fantasise of forcing everyone to use `strict_types`, and making everyone use static analysis tools, but we are a long way off from that happening today... what we can do - make it easy to move to `strict_types` (ideally with good tooling), to sell that approach with the positives it brings, while also keeping non-`strict_types` working as expected so people continue to upgrade. Craig