Синтаксис


  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() и подобных вызовов могут не работать. Исправление варьируется от простого обновления шаблона (например, заэкранировать дефисы) до переписывания шаблонов. Убедитесь, что все ваши тесты проходят.

Комментарии (38)


  1. SerafimArts
    06.09.2018 16:33
    +3

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

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


    1. homm
      07.09.2018 12:54
      +1

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


  1. Hardcoin
    06.09.2018 18:53

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

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


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


    1. SerafimArts
      06.09.2018 19:20

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

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


      1. Hardcoin
        06.09.2018 19:43

        Считаете это нормально?

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


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

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


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

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


        1. VolCh
          06.09.2018 19:53

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


        1. SerafimArts
          06.09.2018 22:11
          +2

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


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


          1. OnYourLips
            07.09.2018 10:45

            Одно только тестирование в часы выльется.


        1. Sabubu
          07.09.2018 02:08
          +1

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


          1. Hardcoin
            07.09.2018 12:50

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


        1. happyproff
          07.09.2018 10:09

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

          Изменения неизбежны, но есть и будут появляться линтеры и всякие compatibility-чекеры, как было для PHP7.


        1. rjhdby
          07.09.2018 10:40

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

          Переходить на новую версию языка — это вам не лобио кушать (с)
          Ни в одном более-менее серьезном проекте невозможна ситуация типа «Ого! Новый пых вышел! Давайте завтра на проме развернем!».
          В целом, регулярки в проекте обычно присутствуют в довольно ограниченном количестве, легко ищутся и без проблем тестируются и исправляются. Не думаю, что в этом случае платить за обратную совместимость поддержкой двух библиотек разумно.


      1. se_pavel
        06.09.2018 19:51

        в сложном коде регулярки могут собираться из частей, поэтому есть смысл в промежуточной версии с notice/warning


      1. zk-zeka
        07.09.2018 09:55

        Да, только особо печально, если проект имеет толстую папку "vendor"…


      1. t_kanstantsin
        07.09.2018 12:01

        Ctrl+F -> «preg»

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


        preg_match($pattern, $subject);

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


        1. SerafimArts
          07.09.2018 13:56

          Блин, точно! Ну ладно, не судьба, у меня идей больше нет.


    1. zzzmmtt
      07.09.2018 09:33

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


      1. Hardcoin
        07.09.2018 12:47
        +1

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


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


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


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


  1. FanatPHP
    07.09.2018 13:03

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

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


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

    вместо


    Json::decode($json);


    1. iGusev Автор
      07.09.2018 13:23

      Это не означает, что нужно именно так писать. Я, например, использую обертку над 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


      1. youROCK
        07.09.2018 13:34

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


        1. iGusev Автор
          07.09.2018 13:43

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


        1. VolCh
          07.09.2018 16:09
          +1

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


      1. FanatPHP
        07.09.2018 14:51

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

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


        1. iGusev Автор
          07.09.2018 15:02

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


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

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


          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.


          1. FanatPHP
            07.09.2018 15:11

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

            ...


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

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


            1. iGusev Автор
              07.09.2018 15:21

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


              1. FanatPHP
                07.09.2018 15:24

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


  1. PQR
    07.09.2018 14:11
    +1

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

    В одном из следующих выпусков рассмотрим стратегии тестирования кода под новую версию PHP, подписывайтесь!


  1. JTG
    07.09.2018 15:20
    +1

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

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

    Без PHPStorm-ских parameter hints вообще печалька.


    1. springimport
      07.09.2018 16:07

      Поэтому нужно использовать класс с параметрами вместо этого.


      1. JTG
        07.09.2018 16:58

        … и когда у класса есть параметры без значений по-умолчанию, получается бомба, которой для безопасной работы уже нужен builder и далее по тексту из «Effective Java 2nd Edition».


  1. KirEv
    07.09.2018 15:30
    +1

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


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


    1. VolCh
      07.09.2018 16:12
      +1

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


      $first_item = $items[\array_key_first($items)];


      1. SerafimArts
        07.09.2018 19:15

        А зачем? Ну т.е. разве не проще ли написать?

        $firstItem = \reset($items);
        


        Или я не понял и это просто сарказм?


        1. rdifb0
          07.09.2018 21:18
          +1

          Не знаю был ли там сарказм. Но код выглядит более интуитивно. Плюс не трогает при этом внутренний указатель массива.


  1. springimport
    07.09.2018 17:11

    Как-то не зацепил релиз, он выглядит скорее как 7.2.1, т.е. работой над ошибками.
    Но это радует

    Забыли про опциональную поддержку AVX инструкций и новый GC (в 3+ раза ускорение).


    1. SerafimArts
      07.09.2018 19:28

      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;
      }
      


      Из чего можно сделать вывод, что конкатенация константных строк и прочее — тоже теперь совершенно, как говорят, бесплатные.