PHP 7.3. Что нового

https://ayesh.me/Upgrade-PHP-7.3
  • Перевод


Синтаксис


  1. Смягчение требований к синтаксису Heredoc и Nowdoc
  2. Поддержка конечных запятых в вызовах функций и методов
  3. Ссылки в list()

Устаревшие возможности (deprecated)


  1. Функция image2wbmp() объявлена устаревшей
  2. Флаги FILTER_FLAG_SCHEME_REQUIRED и FILTER_FLAG_HOST_REQUIRED при использовании FILTER_VALIDATE_URL объявлены устаревшими
  3. Регистро-независимые константы объявлены устаревшими

Новые возможности


  1. Опциональный выброс исключений при ошибках в функциях json_encode и json_decode
  2. Добавление функции is_countable()
  3. Добавление функций array_key_first() и array_key_last()

Изменения


  1. Миграция с PCRE на PCRE2

Смягчение требований к синтаксису Heredoc и Nowdoc


Heredoc и Nowdoc требовали ставить закрывающий идентификатор первым в новой строке.


Пример:


$foo = <<<IDENTIFIER  
the crazy dog jumps over the lazy fox  
"foo" bar;  
IDENTIFIER

Здесь закрывающий IDENTIFIER должен быть первым символом на новой линии чтобы это работало. Кроме того, не должно было быть никаких других символов после закрывающего идентификатора (кроме ;, который является необязательным).


RFC для PHP 7.3 предлагает убрать подобные требования для улучшения читабельности кода. Прежде всего чтобы добавить отступы при использовании heredoc/nowdoc идентификаторов.


Полный список изменений в heredoc/nowdoc синтаксисе:


  1. Закрывающий идентификатор необязательно должен быть первым символом в строке.
  2. Закрывающий идентификатор имеет отсуп пробелами или табами.
  3. Отступ (пробелы или табы) не должен быть смешанным. Если вы это сделаете, то получите Parse error: Invalid indentation - tabs and spaces cannot be mixed in .. on line ...
  4. Точное количество пробелов/табов, используемых перед закрывающим идентефикатором будут удалены из каждой строки heredoc/nowdoc выражения.
  5. Если число отступающих символов, используемых перед закрывающим идентефикатором, больше чем в любой из строк выражения, вы получите Parse error: Invalid body indentation level (expecting an indentation level of at least ..) in .. on line ..
  6. несколько выражений после закрывающего идентификатора будут работать без ошибок

Вот сниппет, который использует новые возможности без нарушения новых правил:


$foo = ['foo', 'bar', <<<EOT  
  baz  
   -  hello world! --  
  ahoy  
  EOT, 'qux', 'quux'  
];

var_dump($foo);

На выводе будет:


array(5) {          
  [0]=>             
  string(3) "foo"   
  [1]=>             
  string(3) "bar"   
  [2]=>             
  string(29) "baz   
  -  hello world! --  
ahoy"  
  [3]=>  
  string(3) "qux"  
  [4]=>  
  string(4) "quux"  
}     `

Обратите внимание, что отступы используемые в декларации при помощи heredoc не отображаются в выводе var_dump(), и мы продолжили перечисление элементов массива после EOT идентификатора.


RFC, обсуждение на Externals.io, реализация


Влияние на обратную совместимость


Пока вы не используете набор идентичных heredox/nowdoc идентификаторам символов в качестве начала строки, вы на коне.


$foo = <<<HELLO  
  HELLO_WORLD <-- это не будет приниматься за окончание строкового литерала
  HELLOWORLD  <-- и это не будет
  HELLO WORLD <-- а это будет 
HELLO;

Если у вас имеется heredoc/nowdoc синтаксис подобный вышеописанному, отмечу, что с PHP 7.3, PHP воспримет первый HELLO литерал и выдаст ошибку на следующей строке. В более ранних версиях HELLO WORLD не воспринимался как закрывающий идентификатор для heredoc. Спасибо /u/ImSuperObjective2 с reddit за указание на это


Поддержка конечных запятых в вызовах функций и методов


Это простое изменение, которое разрешает использование конечных запятых в вызовах функций и методах. Это не влияет на декларирование.


Например, следующий синтаксис станет возможным:


// функция
foo('bar', 'baz',); // Обратите внимание на последнюю запятую после  после 'baz'

В до-PHP-7.3 версиях фрагмент выше выбрасывает ошибку PHP Parse error:  syntax error, unexpected ')' in .. on line ...


Вы не можете использовать более одной запятой в конце или использовать запятые для пропуска аргументов. В основном это изменение для функция с вариативными параметрами. Также с новыми правками синтаксис массива будет выглядеть более последовательным.


Обратите внимание, что Вы не можете использовать эту возможность в объявлениях функций/методов; это неправильно:


function foo($bar, $baz, ) { // nah, you can't do this.  
}

RFC, обсуждение на Externals.io, реализация


Влияние на обратную совместимость


Никакого. Существующий код будет и дальше работать. Если у вас есть вызовы функций принимающие вариативные параметры, добавьте конечные запятые в эти места для удобства. Но использовать их везде — это явно перебор.


Ссылки в list()


Функция list() полезна для быстрого присвоения значений переременным из массива. До версии PHP 7.3 не было возможным указать переменную по ссылке. До PHP 7.3 следующий фрагмент приводил к фатальной ошибке:


$arr = ['apple', 'orange'];  
list($a, &$b) = $arr;  
$b = 'banana';  
echo $arr[1];  
// Fatal error: [] and list() assignments cannot be by reference in .. on line ..

Ссылкаться на non-referencable переменные нельзя: list($a, &$b) = [12, 14]; выдаст Fatal error: Cannot assign reference to non referencable value in .. on line ...


RFC, обсуждение на Externals.io, реализация


Влияние на обратную совместимость


Нет. Вместо того чтобы использовать list() для заполнения нескольких переменных, я бы предложил вам воспользоваться value-объектами, чтобы сделать все проще. Они все равно будут передаваться по ссылке, но сделают ваш код намного чище.


Функция image2wbmp() объявлена устаревшей


image2wbmp() функция из расширения GD используется для вывода изображения в формате WBMP (Wireless Bitmap). В PHP 7.3 она объявлена устаревшей в пользу функции imagewbmp().


Если вы используете image2wbmp(), то просто замените название функции на imagewbmp и все будет хорошо! Более 5,500 упоминаний image2wbmp() на github против более 39,300 упоминаний imagewbmp(). Похоже, команда разработчиков PHP убирает редкоиспользуемые функции, чтобы минимизировать воздействие.


RFC, обсуждение на Externals.io, реализация


Влияние на обратную совместимость


Если вы используете функцию image2wbmp(), замените вызов на imagewbmp. Воспользуйтесь автоматизацией, которая сможет изменить это за вас.


Флаги FILTER_FLAG_SCHEME_REQUIRED и FILTER_FLAG_HOST_REQUIRED при использовании FILTER_VALIDATE_URL объявлены устаревшими


Это движение вперед. Когда вы используете filter_var($var, FILTER_VALIDATE_URL), есть два дополнительных флага, которые можно поставить для обеспечения строгой проверки URL-адреса: FILTER_FLAG_SCHEME_REQUIRED и FILTER_FLAG_HOST_REQUIRED.
Начиная с версии PHP 5.2.1 оба этих флага применяются неявно вне зависимости установлены они или нет.


Если ваш код использует эти флаги, просто удалите их и будет хорошо. На данный момент существует более 5000 результатов поиска на github с их использованием.


RFC, обсуждение на Externals.io, реализация


Влияние на обратную совместимость


Так как оба этих флага объявлены устаревшими, вы увидите уведомление вроде:


Deprecated: filter_var(): explicit use of FILTER_FLAG_SCHEME_REQUIRED and FILTER_FLAG_HOST_REQUIRED is deprecated in ...

Все, что вам нужно сделать — просто удалить два флага, т.к. они и так подразумеваются при использовании FILTER_VALIDATE_URL.


Регистро-независимые константы объявлены устаревшими


Функция define() позволяет объявить константу в регистро-независимом режиме. Вы должны явно объявить константу с учетом регистра, передав третьим параметром функции true. Это не поведение по-умолчанию и наверняка не согласуется с возможностью объявлять константы через ключевое слово const.


define('Foo', 'Bar', true);

Приведенный выше код будет выбрасывать уведомление об устаревании: Deprecated: define(): Declaration of case-insensitive constants is deprecated in ...


Кроме того, при попытке получить доступ к константам, которые были объявлены в режиме без учета регистра (FOO), вы увидете довольно полезное предупреждение: Deprecated: Case-insensitive constants are deprecated. The correct casing for this constant is "Foo"


RFC, обсуждение на Externals.io, реализация


Влияние на обратную совместимость


Вам придется идти в базовый код, туда где объявляются регистро-независимые константы и последовательно исправлять. Крайне маловероятно, что не будет никаких проблем с этим, потому что отловить все варианты использования довольно трудозатратно, но в результате код станет понятней.


Я не нашел на github примеры подобного использования, но как минимум Drupal и WordPress (два довольно старых и зрелых проекта в PHP) имеют регистро-независимые константы.


Опциональный выброс исключений при ошибках в функциях json_encode и json_decode


Одно из моих любимых. Все эти годы json_encode() и json_decode() молчали об ошибках в PHP-переменных или json-строках, что приводило к забагованному коду. Этот случай даже был в знаменитой критике PHP: Фрактал плохого дизайна.


json_decode возвращает null для невалидного ввода, при том, что null — абсолютно верный объект для декодируемого JSON'а. Эта функция абсолютно ненадёжна, если вы конечно не вызываете json_last_error каждый раз при её использовании.

Потребовалось 6 лет после того поста в блоге и у нас появилась возможность получить ошибку о сбоях работы с json:


try {  
  json_decode("{", false, 512, JSON_THROW_ON_ERROR);  
}  
catch (\JsonException $exception) {  
  echo $exception->getMessage(); // выводит "Syntax error"  
}

Новый \JsonException является наследником от \Exception, а также константа JSON_THROW_ON_ERROR и сам JsonException находятся в глобальном пространстве имен.


Я настоятельно рекомендую вам начать использовать эту функцию. Есть сторонние библиотеки, такие как daverandom/exceptional-json, реализующие аналогичную функциональность для версий PHP 7.2 и ниже. С появлением этой функции в ядре PHP, вы можете удалить этот пакет и тонны некрасивого шаблонного кода с вызовом json_last_error() в каждом месте где вы работаете с json.


RFC, обсуждение на Externals.io, реализация


Влияние на обратную совместимость


Никакого, если вы не используете собственное исключение и/или константу с такими же именами.


Добавление функции is_countable()


В PHP 7.2 достаточно много устаревших и забагованных функций. Если вы в PHP 7.2. вызываете count() с использованием не-countable переменной, то PHP выведет предупреждение об этом. В общих правках было предложение проверять получаемую перменную на countable до ее использования в count().


countable-переменной является массив или объект реализующий \Countable интерфейс. Так как при проверке будет использоваться много шаблонного кода, в PHP 7.3 появилась новая функция is_countable(), проверяющая переменную на… ну… возможность использования с count().


Я написал полифил для is__countable(), если вы хотите начать использовать эту возможность уже сейчас.


RFC, обсуждение на Externals.io, реализация


Влияние на обратную совместимость


Пока не объявлена своя собственная функция is_countable(), проблем не будет.


Добавление функций array_key_first() и array_key_last()


В PHP существует 75 различных функций для работы с массивами, но до сих пор не было простого способа получить первый и последний ключи массива без изменения указателя массива или перебора всех ключей (через array_keys()) и затем получения первого/последнего значения.


Появились две новые функции, array_key_first() и array_key_last() позволяющие это делать.


В RFC также предлагалось добавить array_value_first() и array_value_last(), но эта часть не прошла голосование.


RFC, обсуждение на Externals.io, реализация


Влияние на обратную совместимость


Если вы не объявляли свои собственные array_key_first() и array_key_last() функции, то проблем не возникнет.


Миграция с PCRE на PCRE2


PHP использует Perl Compatible Regular Expressions или коротко PCRE в библитеке для работы с регулярными выражениями. С версии PHP 7.2 используется 8.x версия легаси-библиотеки PCRE, а в PHP 7.3 уже будет использоваться PCRE2. Обратите внимание, что PCRE2 считается новой библитекой, хотя в значительной степени совместима с PCRE (8.x).


Новая библитека более агрессивна в валидации паттернов и может привести к ошибкам в существующем коде. Следующий фрагмент будет невалидным с PHP 7.3:


preg_match('/[\w-.]+/', '');

PHP выбросит предупреждение Warning: preg_match(): Compilation failed: invalid range in character class at offset 3.
Проблема с шаблоном: чтобы это работало дефис должен быть перемещен в конец или экранирован.


preg_match('/[\w\-.]+/', '');

Приведенный выше код отлично отработает не только с PHP 7.3, а также и с более старыми версиями. В новом паттерне дефис экранирован - в \-. Это самая распространенная проблема из всех с которыми можно столкнуться при решении вопросов совместимости.


Это довольно незначительное изменение, но есть шанс, что все пойдет не так. Сообщение об ошибке указывает на точное положение символа в регулярном выражении. Убедитесь, что тщательно проверили свой код. Проверьте ваши регулярные выражения на совместимость с PCRE2 синтаксисом через Regex Buddy или другой подобный софт. Дополнительные сведения смотрите в описании PCRE2 синтаксиса и устаревшего PCRE синтаксиса.


RFC, обсуждение на Externals.io, реализация


Влияние на обратную совместимость


Так как PCRE2 более придирчив и строг к шаблонам, некоторые из ваших preg_match() и подобных вызовов могут не работать. Исправление варьируется от простого обновления шаблона (например, заэкранировать дефисы) до переписывания шаблонов. Убедитесь, что все ваши тесты проходят.

Поделиться публикацией

Похожие публикации

Комментарии 44
    +9
    Забыли про опциональную поддержку AVX инструкций и новый GC (в 3+ раза ускорение). Ну и принудительный JIT регулярок (раньше нужен был флаг S).

    UPD. Ах да, это же перевод с копипасты чейнджлога, не увидел сразу. Ну тогда вопросов, как говорится, у матросов — нет. =)
      +3

      Блин, ваш комментарий более информативен, чем вся статья )

      +2
      Новая библитека более агрессивна в валидации паттернов и может привести к ошибкам в существующем коде.

      Крайне некрасиво со стороны разработчиков языка. Начать стоило с notice или warning, но так, что бы продолжило работать. А ломать уже в следующей версии. Что б можно было спокойно мигрировать и исправлять сообщения. А так придется выкладывать с риском. Для легаси-кода без тестов (вытянул его с php5.3+php4 до php7.2) — печально.


      Да, я понимаю, что произошла смена библиотеки. Но всё же печально.

        +3
        Для того, чтобы реализовать варнинги и/или нотисы нужно держать одновременно две разные версии библиотеки в ядре и фоллбечить с новой на старую. Считаете это нормально?

        С другой стороны — эту проблему можно решить минут за десять. Ctrl+F -> «preg» и просто проверяете работоспособность регулярных грамматик. Поведение не должно было поменяться. Так что не вижу в этом никакой трагедии.
          +1
          Считаете это нормально?

          Да, это приемлимое решение. Сделать опцию — warning генерить новой либой, результат — старой. Да, падение производительности, но в некоторых случаях отсутствие сбоев важнее.


          Ctrl+F -> «preg» и просто проверяете работоспособность регулярных грамматик.

          Вы имеете ввиду в голове? Минут за 10 можно просмотреть пяток случаев. Я вот вижу тысячу вхождений у нас в проекте. Сделать можно, но не особо увлекательно.


          Так что не вижу в этом никакой трагедии.

          Потому что оцениваете объем работ в 10 минут.

            0
            Ну есть надежда, что умные идешки вскорости будут парсить по новому синтаксису и выводить ошибки. Ну кроме самых запущенных случаев, когда регулярка формируется динамически.
              +2

              Ну фиг знает, возможно да. С другой стороны можно запилить скриптик:
              1) glob по всем файлам
              2) выдираем все регулярки из preg
              3) делаем обычный preg_match на пустоту в try/catch
              4) ловим кривые регулярки и исправляем


              Кажется, что в этом случае действительно на 10 минут работы)

                0
                Одно только тестирование в часы выльется.
                +1
                Это требует много времени, и непонятно, почему разработчики PHP должны его тратить.
                  0

                  По той же причине, по которой они тратят время на поддержание всей прочей обратной совместимости. По той же причине, по которой они бросают warning для undefined constant вместо Fatal.

                  0
                  Почти наверняка появится cli-инструмент, который достанет из вашего кода все регулярки, скопмилирует их и покажет отчёт.

                  Изменения неизбежны, но есть и будут появляться линтеры и всякие compatibility-чекеры, как было для PHP7.
                    +1
                    Да, это приемлимое решение. Сделать опцию — warning генерить новой либой, результат — старой. Да, падение производительности, но в некоторых случаях отсутствие сбоев важнее.

                    Переходить на новую версию языка — это вам не лобио кушать (с)
                    Ни в одном более-менее серьезном проекте невозможна ситуация типа «Ого! Новый пых вышел! Давайте завтра на проме развернем!».
                    В целом, регулярки в проекте обычно присутствуют в довольно ограниченном количестве, легко ищутся и без проблем тестируются и исправляются. Не думаю, что в этом случае платить за обратную совместимость поддержкой двух библиотек разумно.
                    0
                    в сложном коде регулярки могут собираться из частей, поэтому есть смысл в промежуточной версии с notice/warning
                      0
                      Да, только особо печально, если проект имеет толстую папку "vendor"…
                        0
                        Ctrl+F -> «preg»

                        а потом вспоминаем, что часть регулярок хранится в одном месте, а выполняется в другом так:


                        preg_match($pattern, $subject);

                        А потом вспоминаем, что в итоге такая регулярка даже не в самом проект выполняется, а в одной из подключённых библиотек.

                          0
                          Блин, точно! Ну ладно, не судьба, у меня идей больше нет.
                        +1
                        Так для этого собственно и есть ченджлоги и рекомендации по миграции между версиями. Я отчасти с вами согласен, но в любом случае при апдейте версии сначала лучше вычитать changelog, на тестовой среде довести всё до рабочего состояния и потом уже мигрировать боевую среду. Всё становится грустно в случае если легаси-код обфусцирован, в остальных случаях, даже говнокод можно спокойно отревьюить и поправить.
                          +1

                          Я мигрировал легаси через пять версий (с 5.4). А в целом небольшая часть кода ещё с php4 тянется. Так что отчасти соглашусь — конечно мануалы по миграции помогают. Разумеется, changelog внимательно прочитан. По каждой версии.


                          А вот довести до рабочего состояния на тестовом библиотеку десятилетней давности — не так-то просто. К тому же нет смысла (она уже работает), не увлекательно и за это не заплатят. Миграция — это для разработчиков, что б на php5.4 не писать (обновил до 7.2). И исправлять старые библиотеки по warning в логах намного проще.


                          Попробуйте, например, использовать TEST_UNDEFINED_CONSTANT на 7.0 — получите notice. А в 7.2 — warning. Вот это правильный подход — ошибка постепенно растет в уровне, что бы дать всем возможность её исправить без слома совместимости. Скоро будет Fatal.


                          Или, например, использование в качестве конструктора функции с таким же именем (вместо __construct) — они не сломали сразу (а что, старый стиль, кому он нужен) — они сделали Deprecated. Можно спокойно по логам отловить и исправить. За это спасибо разработчикам языка.

                        0
                        Я настоятельно рекомендую вам начать использовать эту функцию.

                        Дадад, и писать каждый раз эту колбасу


                        json_decode($json, false, 512, JSON_THROW_ON_ERROR); 

                        вместо


                        Json::decode($json);
                          0

                          Это не означает, что нужно именно так писать. Я, например, использую обертку над json_decode() из guzzle:


                          /**
                           * Wrapper for json_decode that throws when an error occurs.
                           *
                           * @param string $json    JSON data to parse
                           * @param bool $assoc     When true, returned objects will be converted
                           *                        into associative arrays.
                           * @param int    $depth   User specified recursion depth.
                           * @param int    $options Bitmask of JSON decode options.
                           *
                           * @return mixed
                           * @throws \InvalidArgumentException if the JSON cannot be decoded.
                           * @link http://www.php.net/manual/en/function.json-decode.php
                           */
                          function json_decode($json, $assoc = false, $depth = 512, $options = 0)
                          {
                              $data = \json_decode($json, $assoc, $depth, $options);
                              if (JSON_ERROR_NONE !== json_last_error()) {
                                  throw new \InvalidArgumentException(
                                      'json_decode error: ' . json_last_error_msg()
                                  );
                              }
                              return $data;
                          }

                          В 7.3 будет тоже самое, только теперь в самом PHP

                            0
                            В каждом неймспейсе эту функцию определяете :)? И какую на самом деле функцию ожидают увидеть те, кто этот код читают?
                              0

                              Во всех современных фреймворках есть возможности для сериализации через обертки (например Symfony или Laravel) для безфреймворкового использования подойдет GuzzleHttp::json_decode() или любой другой свой вариант с обработкой на невалидность json.

                                +1
                                В каждом неймспейсе импортируется если нужна в нём, а ожиданий не должно быть у читателей, если они не видят её в use и не видят \ перед именем в вызове. По сути это неопределённое в рамках файла поведение. Нужно код всего проекта изучать, чтобы более-менее уверенно ожидать что json_decode без \ в каком-то неймспейсе вызовет в итоге стандартную функцию
                                0
                                В 7.3 будет тоже самое, только теперь в самом PHP

                                Боюсь, вы не совсем поняли статью, которую переводили.
                                Для вашего удобства я выше процирировал код из неё.

                                  0

                                  Все понятно. Вы недовольны тем, что нужно будет писать чуть более длинную функцию с доп. параметрами:


                                  Я настоятельно рекомендую вам начать использовать эту функцию.

                                  Дадад, и писать каждый раз эту колбасу


                                  json_decode($json, false, 512, JSON_THROW_ON_ERROR); 

                                  вместо


                                  Json::decode($json);

                                  Ответ: нет, писать не нужно, потому что во всех библиотеках давно есть обертки, где все это уже написано. В RFC предлагается начать с малого и не ломать совместимость, для начала сделали так, затем будет изменено поведение по умолчанию:


                                  Future Scope
                                  As mentioned earlier, it may be desirable to deprecate the default behaviour eventually.
                                    0
                                    В 7.3 будет тоже самое, только теперь в самом PHP

                                    ...


                                    писать не нужно, во всех библиотеках давно есть обертки

                                    "У Рабиновича было собственное мнение, но он его категорически не разделял" :)

                                      0

                                      Либо это какой-то троллинг, либо я чего-то не понимаю. В языке была проблема, ее стали решать на уровне языка (а не костылей). В чем неправильность?

                                        0

                                        Речь не про язык, а про статью, которую вы переводили.
                                        Для вашего удобства я цитировал ранее предложение из неё, с которым я не согласен.

                              +1
                              Также о PHP 7.3 можно послушать в подкасте «Пятиминутка PHP» 5minphp.ru/episode36

                              В одном из следующих выпусков рассмотрим стратегии тестирования кода под новую версию PHP, подписывайтесь!
                                +1
                                Есть надежда, что в язык когда-нибудь завезут именованные параметры? json_decode() c «самым нужным параметром в конце» ещё повезло, вот когда в Symfony нужна same-site кука, можно в полной мере почувствовать всю глубину:

                                new Cookie('foo', 'bar', 0, '/', null, false, true, false, Cookie::SAMESITE_STRICT)

                                Без PHPStorm-ских parameter hints вообще печалька.
                                  0
                                  Поэтому нужно использовать класс с параметрами вместо этого.
                                    0
                                    … и когда у класса есть параметры без значений по-умолчанию, получается бомба, которой для безопасной работы уже нужен builder и далее по тексту из «Effective Java 2nd Edition».
                                  +1
                                  Добавление функций array_key_first() и array_key_last()


                                  не прошло и пол-века )
                                    +1

                                    Причём, вангую, подавляющее большинство использований будет в виде


                                    $first_item = $items[\array_key_first($items)];
                                      0
                                      А зачем? Ну т.е. разве не проще ли написать?
                                      $firstItem = \reset($items);
                                      


                                      Или я не понял и это просто сарказм?
                                        +2
                                        Не знаю был ли там сарказм. Но код выглядит более интуитивно. Плюс не трогает при этом внутренний указатель массива.
                                          0
                                          Написать может и проще, но это не чистая функция, а имеющая сайд-эффекты, последствия которых сложно предсказать в общем случае. Ну банально пришёл вам массив по ссылке параметром вашей функции, а где-то снаружи он уже был сначала сброшен, а потом указатель был сдвинут и функция вызывающая вашу функцию никак не ожидает, что вы сбросите указатель. Все, кто напишет \reset в своей функции, проверят можно ли это делать по всему стэку вызовов? Практика показывает, что далеко не все.
                                      +1
                                      Как-то не зацепил релиз, он выглядит скорее как 7.2.1, т.е. работой над ошибками.
                                      Но это радует
                                      Забыли про опциональную поддержку AVX инструкций и новый GC (в 3+ раза ускорение).
                                        +1
                                        7.0+ релизы это полностью работа над ошибками и ядром с перестраиванием потихоньку его в убершнягу с асинхронщиной, JIT, поддержкой FFI и прочими шутками из коробки, вместо работы над синтаксическими плюшками. А результат трудов, которые направлены на создание PHP 8 с некоторой периодичностью вливаются в основную ветку.

                                        Например: Ребята работали над оптимизацией опкода, вынеся математические операции на сторону «фронтэнда» (т.е. части, которая занимается лексером, парсером и генерацией промежуточного кода без рантайма) и получилось, что такой код:

                                        $a = 2 + 3;


                                        Содержит ровно один опкод, который выводится во время компиляции, а не рантайма (под рантаймом я имею ввиду исполнение опкода): Присваивание (ASSIGN) переменной $a значения 5, а следствием этой оптимизации мы получили возможность писать:
                                        
                                        class X {
                                            public const A = [1, 2, 3];
                                            public const B = [4, 5, 6];
                                            public const C = A + B;
                                        }
                                        


                                        Из чего можно сделать вывод, что конкатенация константных строк и прочее — тоже теперь совершенно, как говорят, бесплатные.
                                        0
                                        теперь возможно объявлять массив так?
                                        $arr = ['1', '2', ];
                                          0
                                          Верно
                                            0
                                            массив так 100 лет уже объявлять можно
                                              +1
                                              Угу, кажется, что с первых версий языка trailing comma допускается. По крайней мере в 4ке работало.
                                              0
                                              Короткая запись объявления массива появилась ещё в PHP 5.4, если мне память не изменяет
                                              $arr = ['1','2',];

                                              trailing comma в массивах точно не помню с какой версии, но тоже уже довольно давно есть.
                                              Теперь trailing comma доступна в вызове функции. То бишь в 7.3 допустимо писать так:
                                              $methodResult = $someObject->someMethod($parameterFirst, $parameterSecond,);
                                              $functionResult = someFunction($firstParam, $secondParam,);
                                              

                                            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                            Самое читаемое