Синтаксис
- Смягчение требований к синтаксису Heredoc и Nowdoc
- Поддержка конечных запятых в вызовах функций и методов
- Ссылки в
list()
Устаревшие возможности (deprecated)
- Функция
image2wbmp()
объявлена устаревшей - Флаги
FILTER_FLAG_SCHEME_REQUIRED
иFILTER_FLAG_HOST_REQUIRED
при использованииFILTER_VALIDATE_URL
объявлены устаревшими - Регистро-независимые константы объявлены устаревшими
Новые возможности
- Опциональный выброс исключений при ошибках в функциях
json_encode
иjson_decode
- Добавление функции
is_countable()
- Добавление функций
array_key_first()
иarray_key_last()
Изменения
- Миграция с 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
синтаксисе:
- Закрывающий идентификатор необязательно должен быть первым символом в строке.
- Закрывающий идентификатор имеет отсуп пробелами или табами.
- Отступ (пробелы или табы) не должен быть смешанным. Если вы это сделаете, то получите
Parse error: Invalid indentation - tabs and spaces cannot be mixed in .. on line ..
. - Точное количество пробелов/табов, используемых перед закрывающим идентефикатором будут удалены из каждой строки
heredoc/nowdoc
выражения. - Если число отступающих символов, используемых перед закрывающим идентефикатором, больше чем в любой из строк выражения, вы получите
Parse error: Invalid body indentation level (expecting an indentation level of at least ..) in .. on line ..
- несколько выражений после закрывающего идентификатора будут работать без ошибок
Вот сниппет, который использует новые возможности без нарушения новых правил:
$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)
Hardcoin
06.09.2018 18:53Новая библитека более агрессивна в валидации паттернов и может привести к ошибкам в существующем коде.
Крайне некрасиво со стороны разработчиков языка. Начать стоило с notice или warning, но так, что бы продолжило работать. А ломать уже в следующей версии. Что б можно было спокойно мигрировать и исправлять сообщения. А так придется выкладывать с риском. Для легаси-кода без тестов (вытянул его с php5.3+php4 до php7.2) — печально.
Да, я понимаю, что произошла смена библиотеки. Но всё же печально.
SerafimArts
06.09.2018 19:20Для того, чтобы реализовать варнинги и/или нотисы нужно держать одновременно две разные версии библиотеки в ядре и фоллбечить с новой на старую. Считаете это нормально?
С другой стороны — эту проблему можно решить минут за десять. Ctrl+F -> «preg» и просто проверяете работоспособность регулярных грамматик. Поведение не должно было поменяться. Так что не вижу в этом никакой трагедии.Hardcoin
06.09.2018 19:43Считаете это нормально?
Да, это приемлимое решение. Сделать опцию — warning генерить новой либой, результат — старой. Да, падение производительности, но в некоторых случаях отсутствие сбоев важнее.
Ctrl+F -> «preg» и просто проверяете работоспособность регулярных грамматик.
Вы имеете ввиду в голове? Минут за 10 можно просмотреть пяток случаев. Я вот вижу тысячу вхождений у нас в проекте. Сделать можно, но не особо увлекательно.
Так что не вижу в этом никакой трагедии.
Потому что оцениваете объем работ в 10 минут.
VolCh
06.09.2018 19:53Ну есть надежда, что умные идешки вскорости будут парсить по новому синтаксису и выводить ошибки. Ну кроме самых запущенных случаев, когда регулярка формируется динамически.
SerafimArts
06.09.2018 22:11+2Ну фиг знает, возможно да. С другой стороны можно запилить скриптик:
1) glob по всем файлам
2) выдираем все регулярки из preg
3) делаем обычный preg_match на пустоту в try/catch
4) ловим кривые регулярки и исправляем
Кажется, что в этом случае действительно на 10 минут работы)
Sabubu
07.09.2018 02:08+1Это требует много времени, и непонятно, почему разработчики PHP должны его тратить.
Hardcoin
07.09.2018 12:50По той же причине, по которой они тратят время на поддержание всей прочей обратной совместимости. По той же причине, по которой они бросают warning для undefined constant вместо Fatal.
happyproff
07.09.2018 10:09Почти наверняка появится cli-инструмент, который достанет из вашего кода все регулярки, скопмилирует их и покажет отчёт.
Изменения неизбежны, но есть и будут появляться линтеры и всякие compatibility-чекеры, как было для PHP7.
rjhdby
07.09.2018 10:40Да, это приемлимое решение. Сделать опцию — warning генерить новой либой, результат — старой. Да, падение производительности, но в некоторых случаях отсутствие сбоев важнее.
Переходить на новую версию языка — это вам не лобио кушать (с)
Ни в одном более-менее серьезном проекте невозможна ситуация типа «Ого! Новый пых вышел! Давайте завтра на проме развернем!».
В целом, регулярки в проекте обычно присутствуют в довольно ограниченном количестве, легко ищутся и без проблем тестируются и исправляются. Не думаю, что в этом случае платить за обратную совместимость поддержкой двух библиотек разумно.
se_pavel
06.09.2018 19:51в сложном коде регулярки могут собираться из частей, поэтому есть смысл в промежуточной версии с notice/warning
t_kanstantsin
07.09.2018 12:01Ctrl+F -> «preg»
а потом вспоминаем, что часть регулярок хранится в одном месте, а выполняется в другом так:
preg_match($pattern, $subject);
А потом вспоминаем, что в итоге такая регулярка даже не в самом проект выполняется, а в одной из подключённых библиотек.
zzzmmtt
07.09.2018 09:33Так для этого собственно и есть ченджлоги и рекомендации по миграции между версиями. Я отчасти с вами согласен, но в любом случае при апдейте версии сначала лучше вычитать changelog, на тестовой среде довести всё до рабочего состояния и потом уже мигрировать боевую среду. Всё становится грустно в случае если легаси-код обфусцирован, в остальных случаях, даже говнокод можно спокойно отревьюить и поправить.
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. Можно спокойно по логам отловить и исправить. За это спасибо разработчикам языка.
FanatPHP
07.09.2018 13:03Я настоятельно рекомендую вам начать использовать эту функцию.
Дадад, и писать каждый раз эту колбасу
json_decode($json, false, 512, JSON_THROW_ON_ERROR);
вместо
Json::decode($json);
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
youROCK
07.09.2018 13:34В каждом неймспейсе эту функцию определяете :)? И какую на самом деле функцию ожидают увидеть те, кто этот код читают?
VolCh
07.09.2018 16:09+1В каждом неймспейсе импортируется если нужна в нём, а ожиданий не должно быть у читателей, если они не видят её в use и не видят \ перед именем в вызове. По сути это неопределённое в рамках файла поведение. Нужно код всего проекта изучать, чтобы более-менее уверенно ожидать что json_decode без \ в каком-то неймспейсе вызовет в итоге стандартную функцию
FanatPHP
07.09.2018 14:51В 7.3 будет тоже самое, только теперь в самом PHP
Боюсь, вы не совсем поняли статью, которую переводили.
Для вашего удобства я выше процирировал код из неё.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.FanatPHP
07.09.2018 15:11В 7.3 будет тоже самое, только теперь в самом PHP
...
писать не нужно, во всех библиотеках давно есть обертки
"У Рабиновича было собственное мнение, но он его категорически не разделял" :)
iGusev Автор
07.09.2018 15:21Либо это какой-то троллинг, либо я чего-то не понимаю. В языке была проблема, ее стали решать на уровне языка (а не костылей). В чем неправильность?
FanatPHP
07.09.2018 15:24Речь не про язык, а про статью, которую вы переводили.
Для вашего удобства я цитировал ранее предложение из неё, с которым я не согласен.
PQR
07.09.2018 14:11+1Также о PHP 7.3 можно послушать в подкасте «Пятиминутка PHP» 5minphp.ru/episode36
В одном из следующих выпусков рассмотрим стратегии тестирования кода под новую версию PHP, подписывайтесь!
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 вообще печалька.springimport
07.09.2018 16:07Поэтому нужно использовать класс с параметрами вместо этого.
JTG
07.09.2018 16:58… и когда у класса есть параметры без значений по-умолчанию, получается бомба, которой для безопасной работы уже нужен builder и далее по тексту из «Effective Java 2nd Edition».
KirEv
07.09.2018 15:30+1Добавление функций array_key_first() и array_key_last()
не прошло и пол-века )VolCh
07.09.2018 16:12+1Причём, вангую, подавляющее большинство использований будет в виде
$first_item = $items[\array_key_first($items)];
SerafimArts
07.09.2018 19:15А зачем? Ну т.е. разве не проще ли написать?
$firstItem = \reset($items);
Или я не понял и это просто сарказм?rdifb0
07.09.2018 21:18+1Не знаю был ли там сарказм. Но код выглядит более интуитивно. Плюс не трогает при этом внутренний указатель массива.
springimport
07.09.2018 17:11Как-то не зацепил релиз, он выглядит скорее как 7.2.1, т.е. работой над ошибками.
Но это радует
Забыли про опциональную поддержку AVX инструкций и новый GC (в 3+ раза ускорение).
SerafimArts
07.09.2018 19:287.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; }
Из чего можно сделать вывод, что конкатенация константных строк и прочее — тоже теперь совершенно, как говорят, бесплатные.
SerafimArts
Забыли про опциональную поддержку AVX инструкций и новый GC (в 3+ раза ускорение). Ну и принудительный JIT регулярок (раньше нужен был флаг S).
UPD. Ах да, это же перевод с копипасты чейнджлога, не увидел сразу. Ну тогда вопросов, как говорится, у матросов — нет. =)
homm
Блин, ваш комментарий более информативен, чем вся статья )