SavePearlHarbor

PHP 8.6: дата релиза, предстоящие возможности и статус RFC

—

от автора

admin

Уже много лет PHP выпускает мажорные версии примерно в конце ноября. PHP 8.5 вышел 20 ноября 2025 года, а PHP 8.4.0 — в конце ноября 2024 года. Если проект сохранит тот же ритм, PHP 8.6 с наибольшей вероятностью выйдет в третью неделю ноября 2026 года. Разумно ожидать релиз в четверг (как и у последних мажорных версий), так что ориентируйтесь примерно на 19 ноября 2026 года или 26 ноября 2026 года, а точная дата будет зависеть от того, сколько потребуется RC.

Принято или уже реализуется к следующему релизу

Частичное применение функций (PFA, v2). Статус: Принят

Это нововведение добавляет синтаксис на основе плейсхолдеров для частичного применения аргументов к любому вызываемому объекту (callable). Если вы вызываете функцию и оставляете один или несколько аргументов плейсхолдерами, PHP возвращает замыкание (Closure), которое запоминает то, что вы уже передали. Позже это замыкание можно вызвать, передав недостающие значения.

<?phpfunction add(int $a, int $b, int $c): int{    return $a + $b + $c;}$add10AndX = add(10, ?, 5);  // возвращает Closure: fn(int $b): intecho $add10AndX(3);          // 18

Здесь создаётся замыкание, потому что ? помечает недостающий аргумент. $add10AndX — ключевая переменная: она хранит вызываемый объект, который можно использовать повторно. Если у callable строгие типы параметров, замыкание их сохраняет, так что вы по-прежнему будете видеть корректные ошибки типов.

Особенно ярко это проявляется в коде, насыщенном колбэками.

<?php$strings = ['hello world', 'hello php'];$replaceHello = str_replace('hello', 'hi', ?);$result = array_map($replaceHello, $strings);var_dump($result);

str_replace('hello', 'hi', ?) возвращает замыкание, которое ожидает третий аргумент. Это замыкание можно напрямую передать в array_map().

Пограничный случай: если вы частично применяете callable, принимающий аргументы по ссылке, точное поведение зависит от итоговых правил RFC, поэтому при работе со ссылками сверяйтесь с RFC.

RFC: https://wiki.php.net/rfc/partial_function_application_v2

clamp(). Статус: Принят

Предлагается нативная функция clamp(), которая удерживает значение в диапазоне min/max. Если значение меньше min, вы получаете min. Если больше max — получаете max.

<?php$percent = 140;echo clamp($percent, 0, 100); // 100

$percent — ваше входное значение. 0 и 100 — границы, которые входят в диапазон. Если вы случайно передадите min > max, ожидается, что clamp() выбросит ValueError, так что не рассчитывайте на молчаливые корректировки.

RFC: https://wiki.php.net/rfc/clamp_v2

Как только PHP 8.6 выйдет в свет, первой российской IDE поддержавшей все нововведения станет OpenIDE. Уже сейчас в ней реализована первоклассная поддержка PHP, достаточно установить одноименный плагин из маркетплейса. А поддержка Docker, работа с базами данных и 300+ плагинов в маркетплейсе доступны абсолютно бесплатно.

RFC, ещё не принятые для PHP 8.6

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

func_get_args_by_name(). Статус: На обсуждении

Этот RFC предлагает новую функцию, которая возвращает аргументы текущей функции, но при этом для именованных аргументов сохраняет имена параметров в качестве ключей массива. В отличие от func_get_args(), имена не теряются.

<?phpfunction greet(string $name, int $age, ...$extra): array{    return func_get_args_by_name();}var_dump(greet(name: 'Alice', age: 30, 'x', 'y'));

Возвращаемый массив должен содержать ключи вроде name и age для именованных аргументов. Дополнительные позиционные аргументы остаются с числовыми ключами. Пограничный случай: если вы передаёте параметр позиционно, он, скорее всего, окажется с числовым ключом, так что не считайте, что все аргументы именованные.

RFC: https://wiki.php.net/rfc/func_get_args_by_name

Nullable- и non-nullable-операторы приведения типов. Статус: На обсуждении

Предлагаются две новые формы операторов приведения типов:

  • (?type) — пропускает null как null, но для не-null-значений по-прежнему выполняет проверку и приведение по правилам слабого приведения параметров (weak mode).

  • (!type) — отвергает null, а также значения, которые нельзя привести корректно (без ошибок).

<?php$value = null;var_dump((?int) $value); // nulltry {    var_dump((!int) $value);} catch (TypeError $e) {    echo $e->getMessage(), "\n";}

(?int) предназначен для конвейеров, где null означает осмысленное отсутствие значения. (!int) — для мест, где вам нужен явный отказ вместо молчаливого преобразования.

Пограничный случай: ключевая часть — это сами правила приведения, и они основаны на правилах слабого приведения параметров (weak mode), а не на сегодняшних очень снисходительных преобразованиях.

RFC: https://wiki.php.net/rfc/nullable-not-nullable-cast-operator

Депрекация нечётких приведений скаляров. Статус: На обсуждении

Цель этого RFC — пометить устаревшими «нечёткие» приведения, при которых PHP сейчас молча выполняет преобразования с потерями. Классический пример — частично числовая строка, у которой PHP сохраняет числовой префикс и отбрасывает всё остальное.

<?php$raw = "123abc";// Сегодня это превращается в 123.// По этому RFC ожидается, что такого рода приведение будет вызывать предупреждение об устаревании в PHP 8.6.$value = (int) $raw;var_dump($value);

Если этот RFC пройдёт, практическое решение простое: сначала проверьте, затем приводите.

<?php$raw = "123abc";if (!ctype_digit($raw)) {    throw new InvalidArgumentException('Expected digits only');}$value = (int) $raw;var_dump($value);

ctype_digit() строгая функция: она принимает только строки, состоящие из цифр. А значит, отвергает отрицательные числа и пробельные символы, поэтому выбирайте валидатор, соответствующий правилам вашего ввода.

RFC: https://wiki.php.net/rfc/deprecate-fuzzy-and-null-casts

Депрекации в PHP 8.6. Статус: Черновик

Это зонтичный RFC, собирающий депрекации, предложенные для PHP 8.6. Он устроен так, чтобы отдельные депрекации можно было голосовать по отдельности. Среди примеров, перечисленных сейчас, — депрекация передачи объектов в некоторые функции массивов и zlib, а также депрекация strcoll() и SORT_LOCALE_STRING.

RFC: https://wiki.php.net/rfc/deprecations_php_8_6

Метод values() для BackedEnum. Статус: На обсуждении

Этот RFC добавляет к BackedEnum метод values(), который возвращает все backing-значения в виде индексированного массива. Если вы когда-нибудь писали перечисления и тут же тянулись за array_map(fn($c) => $c->value, Status::cases()), это избавит вас от шаблонного кода.

<?phpenum Status: string{    case Active = 'active';    case Inactive = 'inactive';}var_dump(Status::values());

Если перечисление уже определяет собственный метод values(), он должен продолжать работать. Если вы полагаетесь на конкретный порядок сортировки, уточните, что именно гарантирует RFC (обычно это порядок объявления).

RFC: https://wiki.php.net/rfc/add_values_method_to_backed_enum

Stringable-перечисления. Статус: На обсуждении

Идея — разрешить __toString() у перечислений. Тогда можно было бы напрямую выводить через echo отдельный вариант перечисления (case) с собственным форматированием.

<?phpenum Role: string{    case Admin = 'admin';    public function __toString(): string    {        return $this->value;    }}echo Role::Admin;

Предложение намеренно узкое: оно про то, чтобы дать перечислениям определять __toString(), а не про добавление состояния в перечисления.

RFC: https://wiki.php.net/rfc/stringable-enums

Улучшения обработки ошибок потоков. Статус: На обсуждении

RFC предлагает сделать ошибки потоков более единообразными и более пригодными для программной обработки. RFC описывает добавление структурированного хранения ошибок, опциональное поведение на основе исключений и согласованные коды ошибок для разных обёрток потоков (stream wrappers). Если вам когда-нибудь приходилось жонглировать предупреждениями, обработчиками ошибок и несогласованными сообщениями от разных обёрток потоков — именно в эту проблему и метит RFC.

RFC: https://wiki.php.net/rfc/stream_errors

API кодирования данных. Статус: На обсуждении

Предлагается стандартный API для кодирования и декодирования распространённых base-кодировок. Мотивация — охватить больше вариантов, чем сегодняшние base64_encode() и base64_decode(), включая детали семейства RFC 4648 и дополнительные популярные кодировки.

RFC: https://wiki.php.net/rfc/data_encoding_api

Видимость на уровне пространства имён. Статус: На обсуждении

Вводится новый уровень видимости, записываемый как private(namespace), который разрешает доступ изнутри того же пространства имён. Цель — делиться внутренними API между тесно связанными классами, не открывая их как public для всего приложения.

RFC: https://wiki.php.net/rfc/namespace_visibility

PDO::disconnect() и PDO::isConnected(). Статус: На обсуждении

Предлагаются два метода у PDO:

  • PDO::disconnect() — явно закрыть фактическое соединение.

  • PDO::isConnected() — узнать, установлено ли соединение в данный момент.

Если это пройдёт, у вас появится поддерживаемый способ разорвать соединение, не полагаясь на unset($pdo) и тайминги сборки мусора.

RFC: https://wiki.php.net/rfc/pdo_disconnect

Объектно-ориентированный API для curl (v2). Статус: На обсуждении

Сегодня в PHP хендлы curl являются объектами, но используются они по-прежнему в основном через процедурные функции. Этот RFC предлагает настоящий объектно-ориентированный API поверх объектов curl — с более чистой структурой и лучшей типобезопасностью.

RFC: https://wiki.php.net/rfc/curl_oop_v2

num_available_processors(). Статус: На обсуждении

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

<?php$workers = num_available_processors() ?? 1;echo "Workers: {$workers}\n";

Запасной вариант ?? 1 важен, потому что RFC допускает возврат null в некоторых ситуациях. Не рассчитывайте, что значение всегда соответствует ограничениям CPU affinity, если только RFC явно этого не гарантирует.

RFC: https://wiki.php.net/rfc/num_available_processors

Отказ от 32-битных сборок. Статус: На обсуждении

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

RFC: https://wiki.php.net/rfc/drop_32bit_support

Поддержка валидации по JSON Schema. Статус: На обсуждении

Этот RFC добавляет поддержку JSON Schema в расширение JSON. RFC описывает объекты схем (создаваемые из текста схемы) и валидацию, интегрированную с существующей обработкой ошибок JSON. Если сегодня вы валидируете тела API-запросов по схемам с помощью библиотек, это станет стандартным вариантом.

RFC: https://wiki.php.net/rfc/json_schema_validation

Модификаторы порядка байтов для знаковых целых в pack()/unpack(). Статус: На обсуждении

Предлагается расширить форматные строки pack() и unpack(), чтобы они поддерживали модификаторы порядка байтов (endianness) для форматов знаковых целых. Цель — избавиться от ручных битовых сдвигов, когда вам нужны знаковые целые в порядке байтов little endian или big endian.

RFC: https://wiki.php.net/rfc/pack-unpack-endianness-signed-integers-support

Контекст-менеджеры. Статус: На обсуждении

Вводится конструкция в стиле using (...) { ... }, гарантирующая очистку в конце блока. Основная идея — «получить нечто, выполнить код, всегда освободить» без необходимости вручную писать try/finally в каждом месте. Примеры в RFC сосредоточены на файловых хендлах и транзакциях.

RFC: https://wiki.php.net/rfc/context-managers

True Async. Статус: На обсуждении

Это более масштабное предложение, задающее стандартную модель async и поддержку на уровне движка, к которой смогут подключаться расширения. Оно включает базовый RFC и связанные RFC по областям видимости и engine API. Предложение амбициозное, и это как раз тот случай, когда RFC может растянуться на несколько релизных циклов — если вообще будет принят.

RFC: https://wiki.php.net/rfc/true_async

Engine API для True Async. Статус: На обсуждении

Это сопутствующий RFC, посвящённый API на уровне движка для подключаемых планировщиков, реакторов и пулов потоков. Считайте его инфраструктурой, которая делает возможными разные реализации async, не привязывая PHP жёстко к одному циклу событий (event loop).

RFC: https://wiki.php.net/rfc/true_async_engine_api

Области видимости и структурированный параллелизм в True Async. Статус: На обсуждении

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

RFC: https://wiki.php.net/rfc/true_async_scope

Заключение

Теперь у вас есть реалистичный ориентир по срокам релиза PHP 8.6, опирающийся на недавний ритм релизов в конце ноября. Мы рассмотрели возможности, уже принятые или находящиеся в реализации, включая частичное применение функций и clamp(). Мы сгруппировали все остальные предложенные для PHP 8.6 RFC, которые пока находятся в статусе черновика или на обсуждении, с кратким описанием того, что они изменят. По мере проведения голосований единственный надёжный источник истины — статус каждого конкретного RFC, поэтому следите за тем, какие пункты переходят в статус «Принят» или «Реализован».

Уже сейчас OpenIDE позволяет разрабатывать проекты на Java, Spring, Python, Go, PHP, JavaScript и TypeScript! А поддержка Docker и 300+ плагинов доступны абсолютно бесплатно в маркетплейсе. Пробуйте российскую IDE в деле и подписывайтесь на нас в Telegram или Max, чтобы не пропустить свежие обновления и полезные материалы.

ссылка на оригинал статьи https://habr.com/ru/articles/1053944/