Видалення елемента зі слайса: stable vs unstable remove

1. Що насправді означає «видалити елемент» зі слайса

Коли новачок чує «видалити з масиву», уява малює сцену, ніби в Excel: рядок виділили, натиснули Delete — і світ став кращим. У Go все прагматичніше: слайс — це «віконце» в масив, і в ньому немає вбудованої операції «вирвати елемент із мʼясом». Видалення — це акуратне поєднання зсуву та зміни len, а іноді ще й санітарної обробки хвоста.

Майже будь-яке видалення зі []T можна розкласти на три кроки:

1. закрити дірку (зазвичай зсувом елементів),
2. зменшити довжину (reslice),
3. за потреби очистити хвіст (щоб не залишати сміття й не утримувати памʼять).

Схематично це можна уявити так:

Було:    [A B C D E]  len=5
Видаляємо C (i=2)

Зсув:    [A B D E E]  len=5   (дірку закрито, але хвіст "дублюється")
Reslice: [A B D E]    len=4
Clear:   [A B D E _]  (якщо хочемо занулити звільнений слот)

Це виглядає трохи «низькорівнево», але дає повний контроль: ми точно знаємо, що сталося з даними і чому саме.

2. Stable remove: видаляємо, зберігаючи порядок

Stable remove — це видалення «по-людськи»: якщо елементи йшли в певному порядку, то після видалення вони й далі йдуть у тому самому порядку, просто без одного елемента. Такий спосіб ідеально підходить для списків завдань, історії дій, черг відображення в UI та загалом для всього, де порядок має значення. Ціна — ми копіюємо (зсуваємо) шматок хвоста, а отже, виконуємо трохи більше роботи.

Механіка stable remove через copy

Найпряміший рецепт такий: якщо видаляємо елемент з індексом i, то копіюємо хвіст s[i+1:] на місце s[i:].

package main

import "fmt"

func main() {
	s := []int{10, 20, 30, 40}
	i := 1

	copy(s[i:], s[i+1:])
	fmt.Println(s) // [10 30 40 40]
}

Зверніть увагу на «дублікат» наприкінці. Це нормально: copy перезаписав елементи, але довжину не змінював, тож останній елемент залишився «як був» — або став копією передостаннього. Щоб завершити видалення, нам потрібно зменшити len.

Завершуємо видалення: зменшуємо len і очищаємо хвіст

Тепер зберемо видалення у функцію. Важливо: раз довжина змінюється, функція має повертати новий слайс, а код, який її викликає, — зберігати результат.

package main

import "fmt"

func removeAtStable(s []string, i int) []string {
	if i < 0 || i >= len(s) {
		return s
	}
	copy(s[i:], s[i+1:])
	clear(s[len(s)-1:]) // очищаємо звільнений слот
	return s[:len(s)-1]
}

func main() {
	tasks := []string{"read", "code", "sleep"}
	fmt.Println(removeAtStable(tasks, 1)) // [read sleep]
}

Тут clear(s[len(s)-1:]) очищає звільнений слот. Для string це особливо корисно як дисципліна: ви явно кажете «цей елемент більше не потрібний», і хвіст не утримує старе посилання на рядкові дані.

3. Unstable remove: видаляємо без збереження порядку

Unstable remove — це спосіб для тих випадків, коли порядок елементів неважливий, а швидкість і простота роботи з памʼяттю важливіші. Ідея дуже проста й навіть трохи зухвала: якщо порядок неважливий, покладемо на місце видаленого елемента останній елемент, а довжину зменшимо. Хвіст при цьому майже не зсувається, отже, роботи зазвичай менше.

Уявіть список тимчасових ID, набір активних зʼєднань, пул обʼєктів, колекцію «кандидатів», де порядок не впливає на результат. Там unstable remove може бути дуже доречним.

Механіка unstable remove (swap-with-last)

Ось мінімальна логіка:

package main

import "fmt"

func main() {
	s := []int{10, 20, 30, 40}
	i := 1
	last := len(s) - 1

	s[i] = s[last]
	s = s[:last]

	fmt.Println(s) // [10 40 30]
}

Видалили «20», але «40» стрибнув на його місце. Порядок змінився — саме це й означає «unstable».

Функція unstable remove з прибиранням хвоста

Зробімо акуратну функцію, яка, як і стабільний варіант, перевіряє межі, повертає новий слайс і очищає останній слот.

package main

import "fmt"

func removeAtUnstable(s []string, i int) []string {
	n := len(s)
	if i < 0 || i >= n {
		return s
	}
	s[i] = s[n-1]
	clear(s[n-1:]) // щоб не тримати посилання у хвості
	return s[:n-1]
}

func main() {
	tasks := []string{"read", "code", "sleep"}
	fmt.Println(removeAtUnstable(tasks, 1)) // [read sleep] (порядок міг змінитися)
}

У цьому конкретному прикладі результат може виглядати так само, як stable, тому що елемент «sleep» і так був останнім. Але якби видаляли індекс 0, ви б побачили перестановку.

4. Stable vs unstable: як вибрати стратегію

Коли ви вибираєте стратегію видалення, ви насправді вирішуєте, яку ціну платите за збереження порядку. Stable remove платить копіюванням хвоста, а unstable — тим, що порядок ламається.

Невелика таблиця, щоб закріпити рішення:

І ще одна важлива думка: stable remove простіший для мозку, бо відповідає людським очікуванням. Unstable remove простіший для компʼютера. У житті часто перемагає мозок, але іноді вам справді потрібен «мішок», і тоді unstable remove — чесний і швидкий.

Короткий «офіційний» патерн видалення через append

Є популярна однорядкова форма видалення елемента, яку ви часто бачитимете в чужому коді:

s = append(s[:i], s[i+1:]...)

Фактично це теж stable remove: ми беремо «голову» s[:i] і «хвіст» s[i+1:] та склеюємо їх через append. Такий підхід справді вважають класичним і широко використовують як стандартний рецепт видалення діапазону зі слайса.

Але важливо розуміти дві речі, щоб не перетворити цей рецепт на магічне заклинання.

По-перше, це операція, яка змінює довжину, тому результат обов’язково потрібно присвоїти назад у s. По-друге, під капотом усе одно відбувається копіювання елементів хвоста — просто ви записуєте це «в один рядок», а не у два кроки copy + reslice. Коли ви пишете код для навчання або налагодження, варіант copy + s[:newLen] іноді простіше читати й коментувати.

5. Міні-застосунок «Список справ» і видалення завдань

Зараз ми знову зберемо маленький консольний застосунок, який спирається лише на те, що ви вже вмієте: слайси, функції, fmt, copy, clear. Нехай це буде проста модель: список завдань — це []string, а видалення завдання — це видалення за індексом. Жодних структур чи файлів, тільки чесна робота зі слайсом.

Друк завдань зі зрозумілою нумерацією

Користувач зазвичай рахує від 1, а індекси в Go починаються з 0. Це класичне джерело болю, тому заведімо функцію друку, яка показує номер «по-людськи».

package main

import "fmt"

func printTasks(tasks []string) {
	for i, t := range tasks {
		fmt.Printf("%d) %s\n", i+1, t)
	}
}

func main() {
	printTasks([]string{"read", "code", "sleep"})
	// 1) read
	// 2) code
	// 3) sleep
}

Видалення завдання: stable-варіант

Тепер додамо stable remove в контексті «завдань». Тут порядок майже завжди важливий: якщо ви написали список справ, дивно, коли після видалення другого пункту раптом третій міняється місцями з останнім. Психологічно це сприймається як «застосунок зламався».

package main

import "fmt"

func removeTaskStable(tasks []string, humanNumber int) []string {
	i := humanNumber - 1
	if i < 0 || i >= len(tasks) {
		return tasks
	}
	copy(tasks[i:], tasks[i+1:])
	clear(tasks[len(tasks)-1:])
	return tasks[:len(tasks)-1]
}

func main() {
	tasks := []string{"read", "code", "sleep"}
	tasks = removeTaskStable(tasks, 2)
	fmt.Println(tasks) // [read sleep]
}

Зверніть увагу: ми приймаємо humanNumber, а всередині одразу переводимо його в індекс. Так менше ризиків помилитися на одиницю, бо перетворення зосереджене в одному місці й добре видно.

Видалення завдання: unstable-варіант

А тепер уявімо іншу ситуацію: у нас є список тимчасових маркерів, підписок або активних ID, і порядок узагалі не має значення. Ми хочемо швидко прибрати елемент і не зсувати хвіст.

package main

import "fmt"

func removeTaskUnstable(tasks []string, humanNumber int) []string {
	i := humanNumber - 1
	n := len(tasks)
	if i < 0 || i >= n {
		return tasks
	}
	tasks[i] = tasks[n-1]
	clear(tasks[n-1:])
	return tasks[:n-1]
}

func main() {
	tasks := []string{"A", "B", "C", "D"}
	tasks = removeTaskUnstable(tasks, 2)
	fmt.Println(tasks) // наприклад: [A D C]
}

Тут важливо чесно коментувати зміст: «порядок змінюється». Unstable remove доречний, коли це очікувано й не вводить людину в ступор.

6. Хвіст і памʼять: чому clear поруч із видаленням корисний

Коли ви тільки починаєте, clear поруч із видаленням виглядає як зайве прибирання. Мовляв, ми ж уже зменшили len — хто взагалі побачить хвіст? Проблема в тому, що хвіст може бути невидимим, але все одно впливати на памʼять: доки в базовому масиві лишається посилання на дані, збирач сміття може вважати ці дані досяжними й не звільняти їх.

Це не штучна тема з підручника. Не випадково в деяких стандартних операціях теж явно очищають хвіст через clear, щоб не тримати зайві посилання.

Тому в навчальних прикладах формуємо звичку: якщо ви зменшили len, подумайте, чи потрібно занулити звільнені елементи. Для []int це частіше питання акуратності. Для []string — уже питання гігієни памʼяті. Для слайсів, що містять «важкі» посилання, наприклад великі рядки, це може стати помітним.

Індекси: міні-блок-схема видалення

Видалення часто ламається не через copy, а через індекси. Тому корисно тримати перед очима просту «мисленну блок-схему», особливо коли ви пишете свій перший код без автопідказок.

flowchart TD
    A[Є слайс s та індекс i] --> B{"0 <= i < len(s)?"}
    B -- ні --> C[Нічого не робимо, повертаємо s]
    B -- так --> D["Стабільне видалення: copy(s[i:], s[i+1:])"]
    D --> E["clear(s[len-1:]) за потреби"]
    E --> F["Обрізання: s = s[:len-1]"]
    F --> G[Повертаємо оновлений s]

Якщо ви вибираєте unstable remove, середина змінюється на «s[i] = s[len-1]», а далі все так само: за потреби очищаємо хвіст і зменшуємо len.

7. Типові помилки під час видалення елемента зі слайса

Помилка № 1: зробили copy, але забули зменшити len.
Це дуже часта ситуація: ви зсунули хвіст, подивилися на слайс, побачили «майже правильно», а наприкінці стирчить зайвий елемент-дублікат. Лікується просто: памʼятати, що copy ніколи не змінює len, а фінальний крок видалення — це s = s[:len(s)-1].

Помилка № 2: забули зберегти результат функції видалення.
Якщо ви написали tasks = removeTaskStable(tasks, 2) — усе добре. Якщо просто removeTaskStable(tasks, 2), то всередині функція могла змінити базовий масив, але змінна tasks у вас залишиться з колишньою довжиною. Виходить дивна напівробота: елементи ніби зсунулися, а список не став коротшим.

Помилка № 3: переплутали «номер для людини» та індекс.
Користувач каже «видали завдання номер 1», а ви видаляєте tasks[1], тобто друге. Це та сама помилка на одиницю, яка переслідує програмістів, мов податкова: іноді зненацька. Найкраща профілактика: в одному місці переводити humanNumber у i := humanNumber - 1 і далі всюди використовувати лише i.

Помилка № 4: використовуєте unstable remove там, де порядок важливий.
Unstable remove може бути чудовим, але якщо ви застосували його до «списку справ», користувач побачить, що елементи стрибають місцями, і вирішить: «програма глючить». Це не баг алгоритму, а баг UX. Якщо порядок важливий — беріть stable remove, навіть якщо він копіює більше.

Помилка № 5: не очистили хвіст, а потім здивувалися памʼяті або «спливаючим» значенням.
Навіть якщо ви не плануєте робити reslice назад до cap, хвіст усе одно лишається частиною базового масиву. Для посилальних типів це може утримувати памʼять. Звичка clear(s[newLen:oldLen]) (або хоча б clear(s[len(s)-1:]) під час видалення одного елемента) робить поведінку чеснішою й передбачуванішою, особливо коли дані «важкі».