Doc #76119 [NEW]: Order of array after modification is not defined

From: Date: Tue, 20 Mar 2018 13:19:39 +0000
Subject: Doc #76119 [NEW]: Order of array after modification is not defined
Groups: php.doc.bugs 
Request: Send a blank email to doc-bugs+get-15542@lists.php.net to get a copy of this message
From: mikko dot rantalainen at peda dot net Operating system: Ubuntu Linux 16.04 LTS 64 bit PHP version: 7.2.3 Package: Documentation problem Bug Type: Documentation Problem Bug description:Order of array after modification is not defined Description: ------------ --- From manual page: http://www.php.net/language.types.array --- As evidenced by comments in the manual (documentation) and e.g. https://stackoverflow.com/q/10914730/334451 official PHP documentation does not define order of an array after modifying the array using following syntaxes ($a is assumed to be array with some existing data): $a["previously-unused-key"] = "test1"; $a[] = "test2"; According to https://3v4l.org/ZTB9c all PHP implementations since PHP 4.3.0 append "test1" and "test2" as the last items of the array $a. However, documentation does not say if this can be trusted in future versions. The documentation should explicitly say that the behavior is undefined (resulting array order cannot be trusted for future versions), or it should explicitly say that using syntax $a["unused-key"] = 1 will append a new key-value pair as the last item in the array. (First example after subtitle "Examples" in the manual seems to suggest that this is by design but this needs to be spelled out.) The documentation should also do the same for the case where the key is identical to already used key. It seems that the value is replaced in-place and the order stays intact. If this is by design, it must be spelled out. The way documentation is currently written, neither of these cases can be trusted to behave the same in the future. (Note that missing documentation is about the order of the array, not about keys or values.) Is the test script guaranteed to output the actual results in the future, too? Test script: --------------- <?php $a = array(1 => 1, 'c'=>2, 'b'=>3, 'd'=>4); $a[] = "first value with implicit key"; unset($a['c']); $a['a'] = "new a"; $a[] = "second value with implicit key"; $a['b'] = "replaced b"; var_export($a); Expected result: ---------------- (Currently undefined, hopefully actual result is the expected result in future, too.) Actual result: -------------- array ( 1 => 1, 'b' => 'replaced b', 'd' => 4, 2 => 'first value with implicit key', 'a' => 'new a', 3 => 'second value with implicit key', ) -- Edit bug report at https://bugs.php.net/bug.php?id=76119&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=76119&r=trysnapshot54 Try a snapshot (PHP 5.5): https://bugs.php.net/fix.php?id=76119&r=trysnapshot55 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=76119&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=76119&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=76119&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=76119&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=76119&r=needscript Try newer version: https://bugs.php.net/fix.php?id=76119&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=76119&r=support Expected behavior: https://bugs.php.net/fix.php?id=76119&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=76119&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=76119&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=76119&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=76119&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=76119&r=dst IIS Stability: https://bugs.php.net/fix.php?id=76119&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=76119&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=76119&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=76119&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=76119&r=mysqlcfg

« previous php.doc.bugs (#15542) next »