Блог*

Сделаем слайс по частям и превратим:

const DECOMPOSED: ([u8; 20], usize) = to_ascii(42);
const STR: &str = unsafe { std::mem::transmute(RawSlice {
    ptr: &DECOMPOSED.0 as *const _, // &[u8] неявно приводится к *const [u8],
                                    // а тот уже кастуется в *const u8
    len: DECOMPOSED.1,
})};

fn main() {
    assert_eq!(STR, "42");
}

(В том, что мы берём ссылку от константы, нет ничего плохого из-за static promotion)
Оно работает! Но кое-что меня всё же беспокоит: порядок полей в представлении слайсов не зафиксирован и может поменяться в любой версии. Можем ли мы как-то от этого защититься? Вообще, да... Но нам потребуются фичи nightly (да, я вас немного обманул, когда сказал, что nightly не понадобится, но с другой стороны, для кода, собственно создающего строку, он не нужен):

mod _sanity_check {
    use super::RawSlice;
    use std::mem::transmute;

    const _RAW_SLICE_HAS_RIGHT_REPR: [(); 1] = {
        const SENTINEL: usize = 1342;
        const SENTINEL_SLICE: RawSlice = RawSlice {
            ptr: std::ptr::null(),
            len: SENTINEL,
        };
        [(); (<*const [u8]>::len(unsafe { transmute(SENTINEL_SLICE) }) == SENTINEL) as _]
    };
}

Здесь мы создаём сырой указатель на слайс (и, насколько я понимаю, в данном случае вызов transmute безопасен, поскольку у сырых толстых указателей значительно менее строгие требования к корректности, чем к ссылкам на слайс) с заданной длиной, а потом вынимаем её при помощи метода len сырого указателя. Если мы угадали с порядком полей, то сравнение длин возвратит true, которое будет скастовано в 1usize и, таким образом, образует литерал массива нужного типа. В данный момент код компилируется. Давайте поменяем порядок полей в RawSlice:

#[repr(C)]
struct RawSlice {
    len: usize,
    ptr: *const u8,
}

...и посмотрим, что скажет компилятор:

...expected an array with a fixed size of 1 element, found one with 0 elements

Отлично, ровно то, что мы и хотели (на самом деле мы хотели бы более внятное сообщение об ошибке, но пока что имеем, что имеем).

Есть ещё кое-что, что мне не очень нравится: мы используем массив размером 20 байт в надежде на то, что их хватит для форматирования числа. Что будет, если этого размера не хватит? Давайте понизим размер массива до единицы и проверим:

error: any use of this value will cause an error
  --> src/main.rs:27:9
   |
27 |         ret[i] = (n % 10) as u8 + b'0';
   |         ^^^^^^
   |         |
   |         index out of bounds: the length is 1 but the index is 1
   |         inside `to_ascii` at src/main.rs:27:9
   |         inside `DECOMPOSED` at src/main.rs:50:38
...
50 | const DECOMPOSED: ([u8; 1], usize) = to_ascii(42);
   | --------------------------------------------------
   |
   = note: `#[deny(const_err)]` on by default

Что ж, ожидаемо. Но брать размер с запасом всё же не хочется. Мы не можем знать наперёд, сколько цифр понадобится... Хотя, погодите-ка, можем!

const fn digits_len(mut n: u32) -> usize {
    if n == 0 {
        return 1;
    }
    let mut n_digits = 0;
    while n != 0 {
        n /= 10;
        n_digits += 1;
    }
    n_digits
}

const LEN: usize = digits_len(42);

const fn to_ascii(mut n: u32) -> ([u8; LEN], usize) {
    ...

Отлично, это всё более-менее работает. Но это всё ещё ногострельно! Тут довольно много кода, который можно написать неправильно, а собственно число, для которого делается строка, приходится использовать дважды (да, я в курсе, что можно просто с запасом взять, нет, я не хочу так делать). Можем ли мы всё это как-то инкапсулировать? Можем! При помощи макроса:

macro_rules! make_literal {
    ($n:expr) => {{
        // ^первая пара скобок является частью синтаксиса macro_rules!,
        // а вторая открывает блок
        const VALUE: u32 = $n;
        // далее весь код почти без изменений,
        // только с заменой конкретного значения на VALUE
        const STR: &str = ...;
        STR
    }}
}

Проверим:

const STR: &str = make_literal!(41 + 1);

fn main() {
    assert_eq!(STR, "42");
}

Оно работает!

GitHub

rfcs/text/1414-rvalue_static_promotion.md at master · rust-lang/rfcs

RFCs for changes to Rust. Contribute to rust-lang/rfcs development by creating an account on GitHub.

637 views23:38