ВОЛОДІННЯ (OWNERSHIP)

Вступ

Попередня лекція показала мотивацію: помилки керування пам'яттю коштують дорого, а Rust обіцяє виявляти їх на етапі компіляції. Ця лекція розкриває механізм, який робить це можливим — володіння (ownership). Це не бібліотечна фіча і не опційна практика — це фундаментальна властивість типової системи Rust, з якої компілятор виводить, коли саме звільнити кожну ділянку пам'яті, без збирача сміття і без ручного free(). Зрозуміти володіння — означає зрозуміти, чому Rust-код виглядає так, як виглядає, і чому компілятор іноді "не пускає" код, що здається цілком розумним.

Три правила володіння

Уся модель зводиться до трьох тверджень, які компілятор перевіряє статично:

1. У кожного значення в Rust є змінна, яку називають його власником (owner).
2. У кожен момент часу власник може бути лише один.
3. Коли власник виходить за межі області видимості — значення знищується (викликається drop).

Ці правила виглядають простими, але з них випливає практично вся дисципліна роботи з пам'яттю в мові: немає потреби вручну відстежувати, хто і коли звільнить ресурс — компілятор виводить це з області видимості змінної-власника.

{
    let s = String::from("hello");   // s стає власником рядка
    // тут можна користуватись s
}   // область видимості s закінчилась → компілятор вставляє виклик drop(s)

Важливо: drop викликається автоматично й детерміновано, у зворотному порядку до створення змінних, у точці виходу з блоку — на відміну від збирача сміття, де момент звільнення непередбачуваний.

Стек, купа і типи з Copy-семантикою

Не всі присвоєння в Rust поводяться однаково — це залежить від того, де фізично лежать дані значення.

Прості типи фіксованого розміру, які повністю вміщуються на стеку (i32, f64, bool, char, кортежі з таких типів), реалізують спеціальний маркерний трейт (trait) Copy. Присвоєння такого значення іншій змінній створює побітову копію — обидві змінні лишаються незалежно валідними:

let x = 3101;                 // 0xC1D
let y = x;                    // побітова копія
println!("{} {}", x, y);      // працює: i32 реалізує Copy

Копіювання тут дешеве (кілька байтів), тому робити його типовою поведінкою безпечно й передбачувано. Типи, для яких копіювання можна дозволити за замовчуванням, — це ті, для яких воно не приховує жодної дорогої операції: копія i32 не виділяє пам'ять і нічого не звільняє.

Що таке move

Для типів, дані яких живуть на купі (String, Vec<T>, Box<T>, більшість власних структур із такими полями), присвоєння не копіює дані — воно переміщує власність (move). Стара змінна після цього вважається недійсною, і компілятор більше не дозволить її використати.

let s1 = String::from("hello");
let s2 = s1;               // власність переходить від s1 до s2

println!("{}", s1);        // error[E0382]: value borrowed here after move
// ^ s1 більше не власник — компілятор це знає і не дає скомпілювати

Технічно String — це структура з трьох полів: вказівник на буфер на купі, довжина (len) і місткість (capacity). Коли s1 "переміщується" в s2, копіюються лише ці три поля (24 байти на 64-бітній системі) — сам буфер на купі не чіпається, копіюється лише "заголовок". Це і є причина, чому move дешевий: він не пропорційний розміру даних на купі.

Ключовий наслідок для безпеки пам'яті: якби s1 і s2 обидва лишались валідними власниками одного й того самого буфера, вихід обох з області видимості спричинив би подвійне звільнення (double free) — саме ту помилку з попередньої лекції. Модель "один власник" структурно унеможливлює цей сценарій: після move власник рівно один, отже, і drop буде викликаний рівно один раз.

Чому move, а не копіювання за замовчуванням

Якби String, Vec та подібні типи копіювалися неявно при кожному присвоєнні (як у деяких мовах з семантикою значень), це означало б непередбачувану вартість продуктивності: рядок у мільйон символів копіювався б повністю щоразу, коли його передають далі за кодом, і читач коду не бачив би цієї вартості в жодному синтаксисі. Rust свідомо робить дешеву операцію (move — копія трьох машинних слів) типовою поведінкою, а дорогу (глибоке копіювання) — явною дією, яку треба викликати самому.

Clone — явна глибока копія

Коли справді потрібні дві незалежні копії даних на купі, викликають .clone(). Це виділяє нову ділянку пам'яті і копіює вміст туди — обидві змінні після цього лишаються повноцінними, незалежними власниками своїх даних.

let s1 = String::from("hello");
let s2 = s1.clone();       // глибока копія: нова ділянка пам'яті

println!("{} {}", s1, s2); // ОК: обидві змінні валідні й незалежні

Головна методологічна ідея: дорога операція завжди видна в коді явно. Читач одразу бачить .clone() і розуміє: тут сталася алокація й копіювання. Немає прихованих дорогих операцій за непомітним синтаксисом присвоєння =.

Copy vs Clone: коли який похідний трейт

Для власних типів компілятор може автоматично згенерувати реалізацію обох трейтів через атрибут #[derive(...)] — за умови, що всі поля типу самі реалізують ці трейти.

#[derive(Debug, Clone, Copy)]
struct Point {
    x: i32,
    y: i32,
}

let p1 = Point { x: 1, y: 2 };
let p2 = p1;              // Copy: побітова копія, p1 і далі валідний
println!("{:?} {:?}", p1, p2);

Важливе обмеження: тип не може одночасно реалізовувати Copy і мати власну реалізацію Drop. Це логічно — якщо тип володіє ресурсом, який треба явно звільнити (Drop), побітове копіювання призвело б до кількох "власників" одного ресурсу, а отже, і до подвійного звільнення. Компілятор забороняє це поєднання на етапі компіляції.

Часткове переміщення структур

Move працює й на рівні окремих полів структури. Якщо перемістити одне поле, решта структури лишається доступною (якщо не використовувати структуру цілком):

struct Runner {
    name: String,
    level: u32,   // u32 реалізує Copy
}

let r = Runner { name: String::from("ранер"), level: 3 };
let name = r.name;          // часткове переміщення: r.name переміщено

println!("{}", r.level);    // ОК: level — Copy, і не було переміщене
// println!("{}", r.name);  // помилка: r.name вже переміщено
// println!("{:?}", r);     // помилка: структура частково переміщена, Debug вимагає всіх полів

Компілятор відстежує стан переміщення на рівні окремих полів — це називається "розщепленим запозиченням/переміщенням" (split borrows/moves) і є однією з тонкощів, які часто дивують новачків: структуру не можна використати цілком, якщо хоча б одне її поле вже переміщене, але окремі непереміщені поля лишаються доступними.

Володіння і функції

Передача значення у функцію за значенням (без &) — це move: власність переходить у функцію. Після виклику функції змінна-аргумент у викликача більше не власник (якщо тип не Copy). Функція може повернути власність назад через результат:

fn takes_ownership(s: String) -> String {
    println!("отримав: {}", s);
    s   // повертаємо власність назад викликачу
}

let s1 = String::from("дані");
let s1 = takes_ownership(s1);   // власність пішла у функцію й повернулась
println!("{}", s1);             // s1 знову валідний

Це працює, але незручно: якщо функція мала лише прочитати рядок (наприклад, обчислити довжину), навіщо забирати повне володіння і потім повертати його назад вручну через кожну функцію в ланцюжку викликів? Саме ця незручність — природний місток до наступної лекції: запозичення (&, &mut) дозволяє функції скористатися значенням, не забираючи власність узагалі.

Drop і RAII

Коли власник виходить з області видимості, Rust автоматично викликає метод трейту Drop::drop. Це той самий принцип RAII (Resource Acquisition Is Initialization), знайомий з C++, але в Rust він примусово перевірений компілятором: неможливо забути реалізувати звільнення ресурсу чи випадково викликати його двічі — компілятор гарантує рівно один виклик drop на кожен власник.

struct Guard {
    name: String,
}

impl Drop for Guard {
    fn drop(&mut self) {
        println!("звільняю ресурс: {}", self.name);
    }
}

fn main() {
    let _g = Guard { name: String::from("з'єднання") };
    println!("працюємо...");
}   // тут автоматично викликається _g.drop() → "звільняю ресурс: з'єднання"

Файли, мережеві з'єднання, м'ютекси, дескриптори БД — усе це типово обгортають у структуру з власною реалізацією Drop, і звільнення відбувається детерміновано, синхронно, у точці виходу з області видимості, без збирача сміття і без ручного виклику "close"/"free" в кожному місці, де могла статися помилка (включно з ранніми return чи панікою — drop викликається й під час розкрутки стека при паніці).

Явно викликати x.drop() заборонено компілятором (це призвело б до подвійного виклику при виході з області видимості) — для примусового раннього звільнення використовують вільну функцію std::mem::drop(x), яка просто забирає значення за власністю й одразу дає йому вийти з області видимості.

Підводні камені

Підсумок

Модель володіння Rust будується на трьох простих правилах: у кожного значення один власник, і воно знищується автоматично, коли власник виходить з області видимості. Для типів на стеку фіксованого розміру присвоєння — дешева побітова копія (Copy); для типів на купі — це переміщення власності (move), яке робить стару змінну недійсною і структурно унеможливлює подвійне звільнення пам'яті. Явна глибока копія доступна через .clone() і завжди видна в коді. Передача значення у функцію теж переміщує власність, що часто незручно — і саме ця незручність мотивує наступну тему курсу: запозичення, яке дозволяє користуватися значенням без передачі володіння.