On 6 January 2022 07:29:58 GMT, James Titcumb <ja...@asgrim.com> wrote: >Just thinking out loud, being able to identify an array type might be a way >forward here (using "syntax" already in use by static analysis tools in >docblocks, for familiarity), e.g. > >private array<string, mixed> $property; > >This might "turn off" the automatic type juggling behaviour, for example. >If the existing strict_types=1 mode is on, this might fail: > >$this->property[3] = "hi"; > >If strict_types=0 or not declared, the key would be cast to a string.
Yes, something similar occurred to me earlier, and I honestly think that some new types like this are the only way this can practically be solved. >That said, I know there has been contentious discussion on this and the >related topic of generics multiple times, so don't really want to stir up a >hornet's nest there. It's not so much that generics are contentious, but that they're really, really hard to implement within the context of PHP's other features. It gets complicated really quickly when you need to verify parameter and return types, e.g. to decide if a value of type SortedList<ChildClass> meets a parameter constraint List<ParentClass> Leaving that aside, though, an array type that has certain constraints on assignment might be workable. And a simple pair that only constrain their keys could just be individually named rather than introducing generics. As for the original suggestion, I think some people are underestimating just how disruptive changing this could be. The really big problem is that there is nothing to deprecate, very little to detect with static analysis tools, and very confusing code if you want to support both versions. The following would be perfectly valid PHP both before and after the behaviour change: $a = []; $a[42] = true; $a['42'] = false; $a[ (string)43 ] = true; $a[ (int)'43' ] = false; None of those lines is "wrong", in and of itself, so there's nothing to mark deprecated or warn about; but the result in current PHP is [42 => false, 43 => false]; and with the proposed change, the result would presumably be [42 => true, '42' => false, '43' => true, 43 => false] I can't think of any way one could prepare for this change, other than putting a string cast in front of every array index throughout an entire code base, *and* on every use of array_keys, foreach, etc that *reads* array keys. Unless someone can present a fully working migration plan, this would get a "no" vote from me. Regards, -- Rowan Tommins [IMSoP]
