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

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

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

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

Такой подход поддерживает принцип минимально необходимого доступа: вызывающий код может владеть двунаправленным каналом, а вызываемой функции передаётся только требуемая возможность.

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

Если принимать везде тип chan T, любая функция получает возможность отправлять, получать и закрывать канал. Это повышает риск неправильного использования: функция может прочитать данные, предназначенные другому потребителю, или преждевременно закрыть канал.

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

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

Значение типа chan T можно передать параметру chan<- T, который разрешает только отправку, либо параметру <-chan T, который разрешает только получение. Внутри функции компилятор запрещает недопустимые операции для соответствующего направления.

package main

func produce(out chan<- int) {
    out <- 42
}

func consume(in <-chan int) int {
    return <-in
}

func main() {
    ch := make(chan int, 1)
    produce(ch)
    _ = consume(ch)
}

Переменная ch остаётся двунаправленной после обоих вызовов. Ограничение действует только на параметр out или in внутри конкретной функции. Закрытие канала отличается от отправки и получения: функция с доступом только для отправки может закрыть канал, поэтому направление само по себе не запрещает close.

Обратное преобразование безопасно не всегда: из канала только для отправки нельзя получить возможность получения, а из канала только для получения нельзя получить возможность отправки. Это отражает реальную потерю разрешений, а не временную настройку синтаксиса.

Канал nil сохраняет свои свойства и после передачи с ограниченным направлением. Отправка или получение через него блокируется навсегда, если канал не был заменён другим значением; закрытие nil-канала вызывает панику.

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

В конвейере обработки данных функция-генератор должна отправлять результаты, но не управлять жизненным циклом канала. При передаче ей chan int компилятор не защищает от чтения или лишних операций; при передаче chan<- int контракт функции становится точнее.

Можно передать канал только для отправки, но тогда функция не сможет получать из него данные. Можно оставить двунаправленный тип ради краткости, однако это ухудшит контроль контракта и позволит ошибочные операции. Практичное решение — использовать направленный тип в сигнатуре функции, а закрытие канала выполнять в том компоненте, который отвечает за завершение потока; это уменьшает связанность и риск преждевременного закрытия.

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

Создаёт ли передача канала копию очереди?

Нет. Канальный тип является ссылочным по своей семантике: переданное значение предоставляет доступ к тому же каналу, его очереди и механизмам синхронизации. Копируется значение, описывающее канал, но не сами данные в очереди.

Можно ли закрыть канал только для получения?

Да, направление <-chan T запрещает отправку, но не запрещает close. Однако обычно компонент, который может только получать, не должен закрывать канал: закрытие означает, что отправителей больше не будет, и ответственность за это решение должна находиться у владельца отправки.

Что произойдёт, если передать nil-канал как направленный?

Он останется nil-каналом с тем же направлением. Получение и отправка будут блокироваться навсегда, а close вызовет панику. Направление ограничивает операции компиляционно, но не инициализирует канал и не меняет его поведение при nil.