Обмеження any і comparable

1. Навіщо потрібні обмеження

Коли ви вперше бачите func F[T any](...), здається, що any — це просто прикраса: «ну, хай буде будь-який тип». Насправді constraint — це зовсім не декоративна дужка, а дозвіл на операції всередині generic-коду. Він одразу відповідає на два запитання: які типи можна підставити замість T і що саме можна робити зі значеннями типу T у тілі функції. Саме так generic-код у Go залишається суворо типізованим, а не перетворюється на «якось розберемося під час виконання».

У мові це формалізовано через ідею множини типів: constraint описує набір допустимих типів для параметра типу. Це добре видно в офіційних поясненнях про type parameters і constraints: параметр типу проходить по типах, дозволених обмеженням.

Можна уявити це так, дуже схематично:

flowchart TD
  A["T — параметр типу"] --> B["constraint (обмеження)"]
  B --> C["набір допустимих типів"]
  C --> D["які операції можна виконувати з T у функції"]

2. any: «будь-який тип», але не «будь-який оператор»

any у Go — це наперед визначений псевдонім для порожнього інтерфейсу (історично interface{}), тобто «підходить будь-який тип». Але ключовий момент у тому, що T any не дає вам жодних гарантій щодо операцій. Він каже лише одне: «можна підставити що завгодно». А якщо так, то всередині функції ви не можете, наприклад, безпечно використовувати == або +, бо не всі типи це підтримують.

Думайте про це так: any — це «коробка будь-якого розміру», але без інструкції, що робити з вмістом. Ви можете переносити її, передавати далі, повертати з функції, друкувати «як є» через fmt, але не можете вимагати від вмісту вміння, скажімо, множитися або порівнюватися.

Що з T any зазвичай можна робити

Головна перевага any у тому, що він ідеально підходить для функцій, які не виконують операцій над значенням, а лише переміщують його: повертають, кладуть у структуру, міняють місцями, дістають перший елемент тощо.

Приклад: «поміняти місцями два значення будь-якого типу».

package main

import "fmt"

func Swap[T any](a, b T) (T, T) {
	return b, a
}

func main() {
	x, y := Swap(10, 20)
	fmt.Println(x, y) // 20 10
}

Тут немає ні порівняння, ні арифметики — ми просто переставляємо значення.

Ще приклад: «безпечно взяти перший елемент або сказати, що його немає». Зверніть увагу на прийом var zero T: так ми отримуємо zero value для будь-якого T.

package main

import "fmt"

func First[T any](xs []T) (T, bool) {
	if len(xs) == 0 {
		var zero T
		return zero, false
	}
	return xs[0], true
}

func main() {
	v, ok := First([]string{"go"})
	fmt.Println(v, ok) // go true
}

Цей патерн (T, bool) ви ще не раз зустрінете в Go-коді: він робить «відсутність значення» частиною контракту, а не несподіваним сюрпризом.

Чого з T any робити не можна

Найчастіша пастка: «раз any, значить, я можу порівняти два T через ==». Не можна, бо не всі типи порівнювані.

Псевдоприклад: такий код не скомпілюється.

package main

func EqualBad[T any](a, b T) bool {
	return a == b // compile error: invalid operation: a == b (not comparable)
}

func main() {}

І це хороша новина: помилка виникає на етапі компіляції, а не «колись у користувача в пʼятницю ввечері».

3. comparable: рівність і ключі map

Коли вам справді потрібно порівнювати значення, any уже не підходить: потрібне обмеження, яке гарантує, що операція порівняння визначена. Для цього в Go є наперед визначене обмеження comparable.

В офіційних матеріалах comparable описується як спеціальне обмеження для типів, у яких визначені == і !=. Це тісно пов’язано і з тим, які типи можна використовувати як ключі map: ключі map мають бути порівнюваними.

Мінітаблиця: any vs comparable

Перед тим як писати код, корисно тримати в голові просту таблицю:

any

comparable

Приклад: Contains для будь-яких порівнюваних типів

Ось класика: пошук значення в слайсі через ==. Тут T comparable — мінімально достатнє обмеження.

package main

import "fmt"

func Contains[T comparable](xs []T, v T) bool {
	for _, x := range xs {
		if x == v {
			return true
		}
	}
	return false
}

func main() {
	fmt.Println(Contains([]int{1, 2, 3}, 2))       // true
	fmt.Println(Contains([]string{"a", "b"}, "c")) // false
}

Якби ми написали T any, компілятор не дав би використати ==.

Чому map вимагає comparable

map[K]V у Go влаштований так, що ключі порівнюються і хешуються. Тому ключ має бути порівнюваним. У generic-коді це проявляється дуже буквально: якщо ви хочете використати K як ключ map, constraint на K має бути comparable, інакше компілятор скаже, що ви просите неможливого. Те саме видно й у прикладах зі структурами даних, де спроба зберігати елементи в map[E]... призводить до повідомлення “missing comparable constraint”.

4. Нюанс у Go 1.25: comparable та інтерфейси

Порівняння в Go виглядає безпечним доти, доки ви не натрапите на інтерфейси. Історично в Go можна мати map[any]string, і це компілюється. Але якщо ви спробуєте використати як ключ значення, яке саме по собі не порівнюване, наприклад слайс, отримаєте паніку під час виконання. В офіційному тексті це навіть ілюструють прикладом зі спробою покласти []int{} у map[any]... і отримати runtime error.

Чому це важливо саме для generics? Бо в сучасних версіях Go, зокрема починаючи з Go 1.20, constraint comparable розширили так, щоб він краще працював з інтерфейсними типами на кшталт any як типом-аргументом, і деякі речі, які раніше не компілювалися, тепер компілюються. Але логіка лишилася чесною: якщо всередині інтерфейсу лежить непорівнюване значення, порівняння може завершитися панікою — так само, як і в звичайному коді без generics.

Практичне правило для новачка просте: якщо ваш T comparable — це звичайні типи, як-от числа, рядки або структури без слайсів чи мап, можна працювати спокійно. Якщо ж ви починаєте порівнювати «коробки з невідомою начинкою» на кшталт any як значень, пам’ятайте: компілятор дозволив вам ==, але виконання все ще може сказати «ой».

5. Як обрати: any чи comparable

Коли починаєш писати generics, дуже хочеться зробити все «універсальним»: поставити any усюди, а потім якось порівняємо. Але в Go це не працює саме тому, що Go намагається робити помилки видимими раніше. Тому стратегія зазвичай така: починаємо з найм’якшого обмеження (any) і посилюємо його лише тоді, коли операція справді потрібна.

Якщо функція зберігає, повертає, вибирає або переставляє значення, часто достатньо any. Якщо функція порівнює (==), будує map за ключами, робить set/unique — тоді потрібен comparable. Це і є «мінімально достатній constraint»: він робить код застосовним до максимальної кількості типів, але водночас дозволяє потрібні операції.

6. Приклад: generic-утиліти для застосунку задач

Зараз зробімо це максимально приземлено: уявімо, що в нас є маленький консольний застосунок «список задач». Він ще не ідеальний, але нам важливо інше: ми хочемо, щоб приклади були не абстрактними «яблука-груші», а справді допомагали писати код.

Нехай у задачі є заголовок і теги:

package main

type Task struct {
	Title string
	Tags  []string
}

Дедуплікація: Unique[T comparable]

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

package main

func Unique[T comparable](xs []T) []T {
	seen := make(map[T]struct{}, len(xs))
	out := make([]T, 0, len(xs))
	for _, x := range xs {
		if _, ok := seen[x]; ok {
			continue
		}
		seen[x] = struct{}{}
		out = append(out, x)
	}
	return out
}

Тут T comparable — не «бо красиво», а тому що map[T]struct{} інакше неможливий.

Збираємо теги задач і робимо їх унікальними

Тепер використаємо Unique у прикладній функції.

package main

func AllTags(tasks []Task) []string {
	var tags []string
	for _, t := range tasks {
		tags = append(tags, t.Tags...)
	}
	return Unique(tags)
}

Зверніть увагу: тут generics дають саме те, що треба. Ми пишемо Unique один раз, а потім використовуємо її для []string, []int, []TaskID — для всього, що можна порівняти.

Підрахунок частоти: CountBy[T comparable]

Ще один корисний шаблон — порахувати, скільки разів трапляється кожен елемент. І знову: ключ map має бути порівнюваним, тому T comparable.

package main

func CountBy[T comparable](xs []T) map[T]int {
	m := make(map[T]int, len(xs))
	for _, x := range xs {
		m[x]++
	}
	return m
}

Так можна порахувати частоти тегів, статусів, авторів — чого завгодно, якщо це порівнювано.

Де тут any: GroupBy[T any, K comparable]

Іноді хочеться згрупувати елементи за ключем: задачі за тегом, користувачів за містом, файли за розширенням. Тут дуже добре видно, як кілька constraints працюють одночасно: елементи ми не порівнюємо — отже T any, а ключ групи кладемо в map — отже K comparable.

package main

func GroupBy[T any, K comparable](items []T, keyFn func(T) K) map[K][]T {
	m := make(map[K][]T)
	for _, it := range items {
		k := keyFn(it)
		m[k] = append(m[k], it)
	}
	return m
}

Це чудовий ментальний орієнтир: any для того, що просто переносимо, і comparable для того, що кладемо в ключі map.

Як читати сигнатури стандартної бібліотеки й не боятися

Коли ви почнете дивитися на стандартні пакети з generics, ви побачите сигнатури на кшталт Clone[M ~map[K]V, K comparable, V any](m M) M. У цій лекції нам важлива не вся сигнатура цілком, там є нюанси, які ми зараз не розбираємо, а саме те, що читається майже як українською мовою: ключ K має бути comparable, а значення V може бути any. Це точно відображає природу map: ключ має підтримувати рівність, а значення може бути будь-яким.

Якщо ви навчилися бачити «K comparable» і відразу розуміти «ага, отже ключі порівнювані», ви вже читаєте 70% практичного generic-коду без зайвого болю.

7. Типові помилки під час роботи з any і comparable

Помилка № 1: використовувати T any і намагатися робити ==.
Це одна з найчастіших ситуацій: пишемо «універсальну» функцію, ставимо any, а потім раптом хочеться порівняти a і b. Компілятор цього не дозволить, і це правильно: any не гарантує, що тип підтримує рівність. Лікується просто: або змінюємо constraint на comparable, або приймаємо функцію порівняння, але це вже інша техніка.

Помилка № 2: намагатися зробити map[T]..., де T any.
Виглядає логічно: «ну T же будь-який, отже й ключ будь-який». Але map вимагає порівнюваності ключа, і generic-код має це явно виразити. Якщо ви хочете map[T]int, то T має бути comparable, інакше ви просите компілятор побудувати map на типах, які в принципі не можуть бути ключами.

Помилка № 3: «про всяк випадок» ставити comparable там, де він не потрібен.
Це зворотна крайність. Іноді функція взагалі не порівнює значення і не використовує їх як ключі, але автор ставить comparable просто тому, що «так безпечніше». Насправді це погіршує API: ви забороняєте використовувати функцію для непорівнюваних типів, наприклад для []byte, хоча могли б спокійно працювати з ними, якби залишили any.

Помилка № 4: вважати, що comparable гарантує відсутність паніки у 100% випадків.
У більшості прикладних сценаріїв це майже так, і саме тому comparable такий зручний. Але якщо ви працюєте з інтерфейсними значеннями, наприклад ключ типу any, усередині якого може опинитися непорівнюваний динамічний тип, порівняння або використання в map може призвести до паніки під час виконання — точно так само, як і в звичайному коді без generics. Цю межу корисно пам’ятати, щоб потім не дивуватися фразі «hash of unhashable type».

Помилка № 5: плутати «тип any» і «параметр типу T з constraint any».
На вигляд це однаково, але сенс різний. any як конкретний тип — це інтерфейсне значення, яке може зберігати різні динамічні типи. T any — це параметр типу, який після підстановки стає конкретним типом. Іноді саме через цю плутанину люди очікують від T any поведінки «як у interface{}», хоча насправді це статично підставлюваний тип.