> On 7 May 2022, at 10:01, Marco Pivetta <ocram...@gmail.com> wrote: > > Hey Craig
Hi Marco, Thanks for your thoughts. > On Sat, 7 May 2022, 10:39 Craig Francis, <cr...@craigfrancis.co.uk > <mailto:cr...@craigfrancis.co.uk>> wrote: > Not what I'm going for... but anyway, to get an idea of your position, do you > think the string '15' should be coerced to a number, or should it fatal error > as well? e.g. > > $my_number = round($request->get('my_number')); > > Passing '15' for `int` should throw a type error: this is why people (slowly, > steadily) opt into strict types. I don't think everyone agrees :-) > I mostly refrained from commenting on this RFC thus far exactly because I'm > already "out of the woods", and I already add strict types everywhere. > > Still, when upgrading legacy PHP apps, I would have to deal with the problem, > at which point I prefer looking for type errors in internal function calls, > than looking for changes in null coercion (the one proposed here) everywhere. > > Practically, my idea is: > > * coercion rules are old and well known > * changing coercion rules around `null` drags in complexity > * focus should be in migrating to strict types instead > > Regardless of the output of this RFC, people upgrading to 8.0 or 8.1 will > already experience BC breaks in internal function input types, and adapt to > them. I will note that my RFC does not change NULL coercion (why I quoted the documentation), and I'm not against the other BC breaks where certain type coercions are clearly problematic. It was 8.1 which introduced this specific BC problem (with ignorable deprecation notices)... and while that change was to begin alignment with user defined functions, it's the user defined functions that have been the oddity (i.e. do not use NULL coercion, unlike other contexts, such as concatenation, == comparisons, arithmetics, sprintf, print, echo, array keys). Personally I think it should have been user defined functions that worked with the "old and well known" coercion rules, and doing so would have reduced complexity (i.e. working in the same way). I'm also not against increasing strictness, and some of the type errors (ref previous emails, and noted in my RFC), but I think it's more of a balance, where an overly strict environment creates different problems (e.g. making the language much more verbose, and can be unnecessarily hard to learn/use). But my focus is on upgrading existing code, and this one is difficult to find and update (e.g. the lack of tooling to help). Craig
