From: Anatol Belski Date: Thu, 17 Sep 2015 11:19:30 +0000 (+0200) Subject: make room for next UPGRADING notes X-Git-Tag: php-7.1.0alpha1~1152 X-Git-Url: https://granicus.if.org/sourcecode?a=commitdiff_plain;h=0f71d006e8335bc64275fd976fc310e43e3d8add;p=php make room for next UPGRADING notes --- diff --git a/UPGRADING b/UPGRADING index aa5f82c49a..18a69cb190 100644 --- a/UPGRADING +++ b/UPGRADING @@ -1,4 +1,4 @@ -PHP 7.0 UPGRADE NOTES +PHP 7.1 UPGRADE NOTES 1. Backward Incompatible Changes 2. New Features @@ -19,776 +19,51 @@ 1. Backward Incompatible Changes ======================================== -Language changes -================ - -Changes to variable handling ----------------------------- - -* Indirect variable, property and method references are now interpreted with - left-to-right semantics. Some examples: - - $$foo['bar']['baz'] // interpreted as ($$foo)['bar']['baz'] - $foo->$bar['baz'] // interpreted as ($foo->$bar)['baz'] - $foo->$bar['baz']() // interpreted as ($foo->$bar)['baz']() - Foo::$bar['baz']() // interpreted as (Foo::$bar)['baz']() - - To restore the previous behavior add explicit curly braces: - - ${$foo['bar']['baz']} - $foo->{$bar['baz']} - $foo->{$bar['baz']}() - Foo::{$bar['baz']}() - -* The global keyword now only accepts simple variables. Instead of - - global $$foo->bar; - - it is now required to write the following: - - global ${$foo->bar}; - -* Parentheses around variables or function calls no longer have any influence - on behavior. For example the following code, where the result of a function - call is passed to a by-reference function - - function getArray() { return [1, 2, 3]; } - - $last = array_pop(getArray()); - // Strict Standards: Only variables should be passed by reference - $last = array_pop((getArray())); - // Strict Standards: Only variables should be passed by reference - - will now throw a strict standards error regardless of whether parentheses - are used. Previously no notice was generated in the second case. - -* Array elements or object properties that are automatically created during - by-reference assignments will now result in a different order. For example - - $array = []; - $array["a"] =& $array["b"]; - $array["b"] = 1; - var_dump($array); - - now results in the array ["a" => 1, "b" => 1], while previously the result - was ["b" => 1, "a" => 1]; - -Relevant RFCs: -* https://wiki.php.net/rfc/uniform_variable_syntax -* https://wiki.php.net/rfc/abstract_syntax_tree - -Changes to list() ------------------ - -* list() will no longer assign variables in reverse order. For example - - list($array[], $array[], $array[]) = [1, 2, 3]; - var_dump($array); - - will now result in $array == [1, 2, 3] rather than [3, 2, 1]. Note that only - the **order** of the assignments changed, but the assigned values stay the - same. E.g. a normal usage like - - list($a, $b, $c) = [1, 2, 3]; - // $a = 1; $b = 2; $c = 3; - - will retain its current behavior. - -* Empty list() assignments are no longer allowed. As such all of the following - are invalid: - - list() = $a; - list(,,) = $a; - list($x, list(), $y) = $a; - -* list() no longer supports unpacking strings (while previously this was only - supported in some cases). The code - - $string = "xy"; - list($x, $y) = $string; - - will now result in $x == null and $y == null (without notices) instead of - $x == "x" and $y == "y". Furthermore list() is now always guaranteed to - work with objects implementing ArrayAccess, e.g. - - list($a, $b) = (object) new ArrayObject([0, 1]); - - will now result in $a == 0 and $b == 1. Previously both $a and $b were null. - -Relevant RFCs: -* https://wiki.php.net/rfc/abstract_syntax_tree#changes_to_list -* https://wiki.php.net/rfc/fix_list_behavior_inconsistency - -Changes to foreach ------------------- - -* Iteration with foreach() no longer has any effect on the internal array - pointer, which can be accessed through the current()/next()/etc family of - functions. For example - - $array = [0, 1, 2]; - foreach ($array as &$val) { - var_dump(current($array)); - } - - will now print the value int(0) three times. Previously the output was int(1), - int(2) and bool(false). - -* When iterating arrays by-value, foreach will now always operate on a copy of - the array, as such changes to the array during iteration will not influence - iteration behavior. For example - - $array = [0, 1, 2]; - $ref =& $array; // Necessary to trigger the old behavior - foreach ($array as $val) { - var_dump($val); - unset($array[1]); - } - - will now print all three elements (0 1 2), while previously the second element - 1 was skipped (0 2). - -* When iterating arrays by-reference, modifications to the array will continue - to influence the iteration. However PHP will now do a better job of - maintaining a correct position in a number of cases. E.g. appending to an - array during by-reference iteration - - $array = [0]; - foreach ($array as &$val) { - var_dump($val); - $array[1] = 1; - } - - will now iterate over the appended element as well. As such the output of this - example will now be "int(0) int(1)", while previously it was only "int(0)". - -* Iteration of plain (non-Traversable) objects by-value or by-reference will - behave like by-reference iteration of arrays. This matches the previous - behavior apart from the more accurate position management mentioned in the - previous point. - -* Iteration of Traversable objects remains unchanged. - -Relevant RFC: https://wiki.php.net/rfc/php7_foreach - -Changes to parameter handling ------------------------------ - -* It is no longer possible to define two function parameters with the same name. - For example, the following method will trigger a compile-time error: - - public function foo($a, $b, $unused, $unused) { - // ... - } - - Code like this should be changed to use distinct parameter names, for example: - - public function foo($a, $b, $unused1, $unused2) { - // ... - } - -* The func_get_arg() and func_get_args() functions will no longer return the - original value that was passed to a parameter and will instead provide the - current value (which might have been modified). For example - - function foo($x) { - $x++; - var_dump(func_get_arg(0)); - } - foo(1); - - will now print "2" instead of "1". This code should be changed to either - perform modifications only after calling func_get_arg(s) - - function foo($x) { - var_dump(func_get_arg(0)); - $x++; - } - - or avoid modifying the parameters altogether: - - function foo($x) { - $newX = $x + 1; - var_dump(func_get_arg(0)); - } - -* Similarly exception backtraces will no longer display the original value that - was passed to a function and show the modified value instead. For example - - function foo($x) { - $x = 42; - throw new Exception; - } - foo("string"); - - will now result in the stack trace - - Stack trace: - #0 file.php(4): foo(42) - #1 {main} - - while previously it was: - - Stack trace: - #0 file.php(4): foo('string') - #1 {main} - - While this should not impact runtime behavior of your code, it is worthwhile - to be aware of this difference for debugging purposes. - - The same limitation also applies to debug_backtrace() and other functions - inspecting function arguments. - -Relevant RFC: https://wiki.php.net/phpng - -Changes to integer handling ---------------------------- - -* Invalid octal literals (containing digits larger than 7) now produce compile - errors. For example, the following is no longer valid: - - $i = 0781; // 8 is not a valid octal digit! - - Previously the invalid digits (and any following valid digits) were simply - ignored. As such $i previously held the value 7, because the last two digits - were silently discarded. - -* Bitwise shifts by negative numbers will now throw an ArithmeticError: - - var_dump(1 >> -1); - // ArithmeticError: Bit shift by negative number - -* Left bitwise shifts by a number of bits beyond the bit width of an integer - will always result in 0: - - var_dump(1 << 64); // int(0) - - Previously the behavior of this code was dependent on the used CPU - architecture. For example on x86 (including x86-64) the result was int(1), - because the shift operand was wrapped. - -* Similarly right bitwise shifts by a number of bits beyond the bit width of an - integer will always result in 0 or -1 (depending on sign): - - var_dump(1 >> 64); // int(0) - var_dump(-1 >> 64); // int(-1) - -Relevant RFC: https://wiki.php.net/rfc/integer_semantics - -Changes to string handling --------------------------- - -* Strings that contain hexadecimal numbers are no longer considered to be - numeric and don't receive special treatment anymore. Some examples of the - new behavior: - - var_dump("0x123" == "291"); // bool(false) (previously true) - var_dump(is_numeric("0x123")); // bool(false) (previously true) - var_dump("0xe" + "0x1"); // int(0) (previously 16) - - var_dump(substr("foo", "0x1")); // string(3) "foo" (previously "oo") - // Notice: A non well formed numeric value encountered - - filter_var() can be used to check if a string contains a hexadecimal number - or convert such a string into an integer: - - $str = "0xffff"; - $int = filter_var($str, FILTER_VALIDATE_INT, FILTER_FLAG_ALLOW_HEX); - if (false === $int) { - throw new Exception("Invalid integer!"); - } - var_dump($int); // int(65535) - -* Due to the addition of the Unicode Codepoint Escape Syntax for double-quoted - strings and heredocs, "\u{" followed by an invalid sequence will now result in - an error: - - $str = "\u{xyz}"; // Fatal error: Invalid UTF-8 codepoint escape sequence - - To avoid this the leading backslash should be escaped: - - $str = "\\u{xyz}"; // Works fine - - However, "\u" without a following { is unaffected. As such the following code - won't error and will work the same as before: - - $str = "\u202e"; // Works fine - -Relevant RFCs: -* https://wiki.php.net/rfc/remove_hex_support_in_numeric_strings -* https://wiki.php.net/rfc/unicode_escape - -Changes to error handling -------------------------- - -* There are now two exception classes: Exception and Error. Both classes - implement a new interface Throwable. Type hints in exception handling code - may need to be changed to account for this. - -* Some fatal errors and recoverable fatal errors now throw an Error instead. - As Error is a separate class from Exception, these exceptions will not be - caught by existing try/catch blocks. - - For the recoverable fatal errors which have been converted into an exception, - it is no longer possible to silently ignore the error from an error handler. - In particular, it is no longer possible to ignore type hint failures. - -* Parser errors now generate a ParseError that extends Error. Error - handling for eval()s on potentially invalid code should be changed to catch - ParseError in addition to the previous return value / error_get_last() - based handling. - -* Constructors of internal classes will now always throw an exception on - failure. Previously some constructors returned NULL or an unusable object. - -* The error level of some E_STRICT notices has been changed. - -Relevant RFCs: -* https://wiki.php.net/rfc/engine_exceptions_for_php7 -* https://wiki.php.net/rfc/throwable-interface -* https://wiki.php.net/rfc/internal_constructor_behaviour -* https://wiki.php.net/rfc/reclassify_e_strict - -Other language changes ----------------------- - -* Removed support for static calls to non-static calls form an incompatible - $this context. In this case $this will not be defined, but the call will be - allowed with a deprecation notice. An example: - - class A { - public function test() { var_dump($this); } - } - - // Note: Does NOT extend A - class B { - public function callNonStaticMethodOfA() { A::test(); } - } - - (new B)->callNonStaticMethodOfA(); - - // Deprecated: Non-static method A::test() should not be called statically - // Notice: Undefined variable $this - NULL - - Note that this only applies to calls from an incompatible context. If class B - extended from A the call would be allowed without any notices. - -* It is no longer possible to use the following class, interface and trait names - (case-insensitive): - - bool - int - float - string - null - false - true - - This applies to class/interface/trait declarations, class_alias() and use - statements. - - Furthermore the following class, interface and trait names are now reserved - for future use, but do not yet throw an error when used: - - resource - object - mixed - numeric - -* The yield language construct no longer requires parentheses when used in an - expression context. It is now a right-associative operator with precedence - between the "print" and "=>" operators. This can result in different behavior - in some cases, for example: - - echo yield -1; - // Was previously interpreted as - echo (yield) - 1; - // And is now interpreted as - echo yield (-1); - - yield $foo or die; - // Was previously interpreted as - yield ($foo or die); - // And is now interpreted as - (yield $foo) or die; - - Such cases can always be resolved by adding additional parentheses. - - . Removed ASP (<%) and script (