On Tue, Jun 18, 2024 at 10:46 PM Rowan Tommins [IMSoP] <imsop....@rwec.co.uk> wrote: > > 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); >
This is nice. I like it :) > > > 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. > I honestly don't know how the deprecation would work, or what makes sense. Supporting both makes sense and as long as the behavior stays exactly the same, and they are both set to the same thing, that would probably be fine for awhile. Is it confusing... I wouldn't find it confusing unless I was working on something that supported <9 and >9 and eventually 8.x will EoL and then it won't be so confusing anymore. > > 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. I've been mulling this around in my head last night and this morning. I think I have something that makes sense, based mostly on information loss. Essentially, an int could become a float (within some limits), but a float can only become an int if it is an int itself. The same concept of a string, where "123test" couldn't become a number because "test" would be lost. Booleans are tricky, but I'd be inclined to keep it as-is; otherwise, the BC break would be unbearable. I think something like that would logically make sense. Whether or not it would be feasible to implement in a performant way, I have no idea (but it would be nice to clean up that area of the C code since it's a bit of a tangle, IMHO). Interestingly, we could still do normal coercion but just warn when there is information loss. Then, people can ignore/catch those warnings and do whatever they want with them. If information loss is what you want and you want to get rid of the warning, you can simply add an explicit cast, but it would be nice also to adjust casting so you can do (int|null) $value; // or (?int) $value so null won't be cast to zero. But that should probably be a totally separate RFC and out of scope atm. > > 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] Robert Landers Software Engineer Utrecht NL
