Показано, как переписать константные дженерики: длина массива наконец сможет вычисляться

ГруппаConst Generics показала, как intends переписать константные дженерики. Это должно снять ограничение, из-за которого в константном параметре нельзя написать вычисляемое выражение.

Какое ограничение снимается

Сейчас в константном параметре допустимы либо отдельный параметр, либо полностью вычисленная константа. Написать [u8; N + 1] или [u8; T::NUM_BYTES] нельзя.

Из-за этого для вычисления длины массива приходится писать макрос на macro_rules! с целочисленным перебором или брать готовый крейт для вычисления целых на этапе компиляции. Оба пути неудобны, и оба — лишняя зависимость или лишний макрос в проекте, которому нужна простая вещь.

Как устроено предложение

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

Новое выражение обязательно пишется внутри макроса. Авторы прямо признают, что это серьёзная проблема эргономики, и говорят, что ищут способ от неё избавиться, но решения пока нет.

Чего ожидать на практике

Ограничение, о котором стоит сказать прямо: обёртка принимает не то же, что фигурные скобки. Вычисления и вызовы функций в ней по-прежнему не работают — конструкции вида gca!(N + 1) и gca!(функция()) не компилируются.

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

То есть это не готовая замена, а задел. Стабилизация прямо отложена: авторы считают, что до готовности ещё далеко, и говорить о предложении как о решении пока рано.

Оригинал

On stable, only generic parameters by themselves (e.g. { N }) or fully concrete constants (e.g. { 1 + 1 }) are supported by Const Generics. It's not possible to have arrays like [u8; T::NUM_BYTES] or [u8; N + 1]. This limitation prevents a lot of useful abstractions and pushes users to rely on the typenum crate instead.

All GCA features require any newly supported expressions to be written inside of a gca! macro call. We are aware that this requirement poses significant ergonomic problems and are currently looking into ways to avoid this.

We're not currently ready to stabilize any of the features talked about in this post.