Hi,
I agree with Stas and Sara. it's easier to revert the last optimization and return to 7.1 behavior (even if it's inconsistent). Fixing this inconsistency in PHP-Next would require RFC. Thanks. Dmitry. ________________________________ From: Stanislav Malyshev <smalys...@gmail.com> Sent: Tuesday, July 4, 2017 3:23:27 AM To: Dmitry Stogov; nikita....@gmail.com; Sara Golemon; Bob Weinand Cc: PHP internals list Subject: Re: [PHP-DEV] 7.2 behavior break, Bug #74836 isset on zero-prefixed numeric indexes in array broken Hi! > > Please take a look at https://bugs.php.net/bug.php?id=74836 > > What is the best option to fix this? > > > The most consistent way, from my point of view - disabling zero-prefexed > numeric strings in all cases, but this is a new behavior break. I think this is very corner case, for string offsets. So for 7.2 to drop support for leading-0 string, with note in UPGRADING and maybe a notice/warning, would be ok. It is not good though that read access and isset are not consistent, this should always work the same. It is especially worrying that "010" and $i = "010" work differently, that should never happen. The problem is if we disable it for string offsets, it would be weird to keep it for array offsets, and so for arrays "010" should be treated as string I guess? Which may involve more breakage. So I wonder if a better way would be to just let it be as it always was, and maybe make leading-0 strings not to be interpreted as numbers for both cases in PHP.next when we can do BC breaks. -- Stas Malyshev smalys...@gmail.com
