On 18/06/2024 17:37, Robert Landers wrote:
One thing is clear is that "strict types" may be a bit of poor word choice and gives people a false sense of security that it is "safe" or "more correct" when this obviously isn't true.
I totally agree with this sentiment. I don't think it should be called "strict", and I don't think it should be "on or off" either.
If I had a time machine, I'd propose something like: declare(scalar_args=coerce); declare(scalar_args=error); Or perhaps: declare(coerce_scalar_args=if_safe); declare(coerce_scalar_args=never); But...
Thus, I'd like to propose, for PHP 9, simply renaming it...
I'm not sure the pain is worth it. We'd have to introduce support gradually, probably not phasing out the old name until 10.0 at the earliest, so you'd just end up with more confusion with people not understanding if they were the same thing, which one to use in which version, etc.
Perhaps it might even be worth adding a secondary vote to flip the default, such that if you want to "old" behavior back
You're falling into the same trap you're describing: assuming that strict_types=0 is an "older" mode, or a "worse" one. Both modes were introduced at exactly the same time, as a direct choice to users between two different styles, which had been proposed in competing RFCs.
Changing the default, and the name, but keeping the same behaviour, would just be a huge mess.
Personally, I would rather unify non-strict and strict in some way that makes sense
I think this is where we should be focussing our attention. We've had some great RFCs over the last few years tightening up some of the weirder excesses of PHP's type juggling system.
With a tight enough definition of "numeric string" and other coercible values, I think "mode 0" could be strict enough that "mode 1" wouldn't feel so necessary.
Then again, I was broadly in favour of the original coercive-only proposal for scalar type parameters, and there are those who felt strongly on the other side. The debate was extremely heated, and I'm not in a hurry to reopen it.
Regards, -- Rowan Tommins [IMSoP]
