Краткий ответ

В Go срезы не являются ковариантными: []КонкретныйТип и []Интерфейс — разные несовместимые типы, даже если КонкретныйТип реализует Интерфейс. Реализация интерфейса гарантируется для отдельного значения, но не распространяется автоматически на контейнер таких значений.

Чтобы передать данные функции, нужно явно создать новый срез интерфейсного типа и поместить в него элементы. Это выполняет поэлементное преобразование и обычно требует дополнительной памяти и времени.

Исторический контекст

Интерфейсы Go предназначены для полиморфизма отдельных значений: конкретное значение можно использовать там, где ожидается реализуемый им интерфейс. При этом язык сохраняет строгую типизацию контейнеров и не вводит неявную ковариантность срезов.

Такой подход упрощает правила типов и сохраняет предсказуемое представление данных в памяти. Срез конкретных значений и срез интерфейсных значений имеют различную структуру элементов, поэтому их нельзя безопасно считать взаимозаменяемыми.

Постановка проблемы

Представим срез []File, где File реализует интерфейс Writer. Было бы удобно передать его функции, принимающей []Writer, но это позволило бы функции записать в срез объект другого типа, который также реализует Writer.

После такой записи исходный срез []File содержал бы не File, а чужой тип. Поэтому автоматическое присваивание нарушило бы типовую безопасность. Go запрещает такую передачу ещё на этапе компиляции.

Подробное решение

Интерфейсная совместимость проверяется для элемента, а не для среза целиком. Поэтому допустимо присваивание одного File переменной типа Writer, но недопустимо присваивание []File переменной типа []Writer.

Элементы []File обычно представлены как сами значения File, тогда как элементы []Writer являются интерфейсными значениями, содержащими динамический тип и динамическое значение. Эти представления и размеры элементов могут различаться.

Минимальный пример явного преобразования:

package main

type Writer interface{ Write() }
type File struct{}
func (File) Write() {}

func use(xs []Writer) {}

func main() {
	files := []File{{}, {}}
	writers := make([]Writer, len(files))
	for i, f := range files {
		writers[i] = f
	}
	use(writers)
}

Цикл создаёт новые интерфейсные значения и копирует в них элементы files. Исходный срез не изменяется, а writers имеет независимое хранилище.

Альтернатива — изменить API функции: принимать обобщённый срез с ограничением, если функции достаточно вызвать методы элементов и не требуется именно []Writer. Однако такой вариант подходит не всегда: например, если API должен хранить разные реализации интерфейса в одном срезе, нужен именно []Writer.

Ситуация из практики

Сервис обработки файлов получает []File, но библиотечный планировщик принимает []Task, где File реализует Task. Рассматривались три варианта: неявно передавать срез, что невозможно; преобразовать срез на границе API; или сделать планировщик обобщённым.

Обобщённый планировщик уменьшил бы число копирований, но усложнил бы API и не позволил бы смешивать разные реализации Task в одном вызове. Выбрано явное преобразование на границе: оно локализует стоимость копирования, сохраняет простой контракт библиотеки и делает изменение типов очевидным.

Что кандидаты часто упускают

Вопрос: Можно ли безопасно заменить []File на []Writer, если функция только читает элементы?

Ответ: В общем случае нет. Сигнатура []Writer допускает операции, изменяющие срез: запись по индексу, передачу в другую функцию или добавление элементов через append. Компилятор не анализирует фактическое поведение конкретного вызова, поэтому запрещает преобразование для всех случаев.
Вопрос: Почему передача []File в обобщённую функцию с параметром []T, где T ограничен интерфейсом Writer, обычно возможна без преобразования к []Writer?

Ответ: При вызове такой функции T выводится как File, поэтому параметр имеет тип []File, а не []Writer. Ограничение проверяет, что File обладает требуемыми методами, но не превращает элементы среза в интерфейсные значения. Это позволяет сохранить исходный тип и избежать копирования, пока функция работает с параметром типа T.
Вопрос: Почему []any не является универсальным контейнером, в который можно напрямую передать любой срез?

Ответ: any — это псевдоним пустого интерфейса, но []any всё равно остаётся отдельным типом с интерфейсными элементами. Срез []int, например, хранит значения int, а []any — отдельные интерфейсные значения для каждого элемента. Поэтому требуется создать []any и поместить значения в него по одному, несмотря на то что каждый отдельный int присваивается переменной типа any.