Channel Direction

In Go, you can specify the direction of a channel when using it as a function parameter. This creates a directional channel that can only be used for sending or receiving, which increases the type safety of your program.

Why Specify Channel Direction?#

Specifying channel direction has several benefits:

Type safety: It prevents accidental reads from send-only channels and accidental writes to receive-only channels
Clear intent: It makes the intended use of a channel obvious in function signatures
Better documentation: It helps document how data flows through your program
Compiler enforcement: The compiler enforces these restrictions, catching errors early

Channel Direction Types#

Go provides three types of channel direction:

Bidirectional channel (chan T): Can be used for both sending and receiving
Send-only channel (chan<- T): Can only be used for sending
Receive-only channel (<-chan T): Can only be used for receiving

Syntax#

Here's how to declare variables of each channel direction type:

example.go

var bidirectional chan string     string">"comment">// can be used for sending and receiving
var sendOnly chan<- string        string">"comment">// can only be used for sending
var receiveOnly <-chan string     string">"comment">// can only be used for receiving

And here's how to use them in function parameters:

example.go

func producer(out chan<- int) {
    string">"comment">// can only send to out
}
 
func consumer(in <-chan int) {
    string">"comment">// can only receive from in
}
 
func processor(in <-chan int, out chan<- int) {
    string">"comment">// can only receive from in and only send to out
}

Channel Direction Conversion#

You can convert a bidirectional channel to a directional channel, but not vice versa:

example.go

ch := make(chan int)       string">"comment">// bidirectional
 
var sendCh chan<- int = ch  string">"comment">// convert to send-only
var recvCh <-chan int = ch  string">"comment">// convert to receive-only
 
string">"comment">// Error: cannot convert directional channel back to bidirectional
string">"comment">// ch = sendCh  // This would not compile

Example: Using Channel Direction#

Here's a practical example showing how to use directional channels:

example.go

package main
 
import string">"fmt"
 
string">"comment">// ping takes a send-only channel
func ping(pings chan<- string, msg string) {
    pings <- msg
}
 
string">"comment">// pong takes a receive-only channel and a send-only channel
func pong(pings <-chan string, pongs chan<- string) {
    msg := <-pings
    pongs <- msg
}
 
func main() {
    pings := make(chan string, 1)
    pongs := make(chan string, 1)
    
    ping(pings, string">"passed message")
    pong(pings, pongs)
    
    fmt.Println(<-pongs)  string">"comment">// prints: passed message
}

In this example:

ping can only send to the pings channel
pong can only receive from the pings channel and only send to the pongs channel
This enforces a clear flow of data in one direction

Common Patterns with Channel Direction#

The Generator Pattern#

A function that generates values and sends them to a channel:

example.go

func generate(numbers ...int) <-chan int {
    out := make(chan int)
    
    go func() {
        defer close(out)
        for _, n := range numbers {
            out <- n
        }
    }()
    
    return out  string">"comment">// Return a receive-only channel
}
 
func main() {
    string">"comment">// Consumer can only receive from the channel
    ch := generate(1, 2, 3, 4)
    
    for n := range ch {
        fmt.Println(n)
    }
}

The Worker Pattern#

A function that processes values from an input channel and sends results to an output channel:

example.go

func worker(id int, jobs <-chan int, results chan<- int) {
    for job := range jobs {
        fmt.Printf(string">"Worker %d processing job %d\n", id, job)
        results <- job * 2
    }
}
 
func main() {
    jobs := make(chan int, 100)
    results := make(chan int, 100)
    
    string">"comment">// Start workers
    for w := 1; w <= 3; w++ {
        go worker(w, jobs, results)
    }
    
    string">"comment">// Send jobs
    for j := 1; j <= 5; j++ {
        jobs <- j
    }
    close(jobs)
    
    string">"comment">// Collect results
    for a := 1; a <= 5; a++ {
        fmt.Println(<-results)
    }
}

The Message Relay Pattern#

A function that relays messages from one channel to another:

example.go

func relay(in <-chan string, out chan<- string) {
    for msg := range in {
        out <- msg  string">"comment">// Forward the message
    }
    close(out)
}
 
func main() {
    ch1 := make(chan string)
    ch2 := make(chan string)
    
    go func() {
        ch1 <- string">"Hello"
        ch1 <- string">"World"
        close(ch1)
    }()
    
    go relay(ch1, ch2)
    
    for msg := range ch2 {
        fmt.Println(msg)
    }
}

Closing Directional Channels#

One important restriction is that you can only close a channel that you can send to. This means:

You can close a bidirectional channel
You can close a send-only channel
You cannot close a receive-only channel

example.go

string">"comment">// Valid
func producer(ch chan<- int) {
    for i := 0; i < 5; i++ {
        ch <- i
    }
    close(ch)  string">"comment">// This is valid
}
 
string">"comment">// Invalid
func consumer(ch <-chan int) {
    for i := range ch {
        fmt.Println(i)
    }
    string">"comment">// close(ch)  // This would be a compilation error
}

Using Type Assertions with Directional Channels#

You can use type assertions to check if a channel is directional:

example.go

func processChannel(ch interface{}) {
    switch c := ch.(type) {
    case chan int:
        fmt.Println(string">"Bidirectional channel")
    case <-chan int:
        fmt.Println(string">"Receive-only channel")
    case chan<- int:
        fmt.Println(string">"Send-only channel")
    default:
        fmt.Println(string">"Not a channel")
    }
}

Best Practices#

Be as restrictive as possible: Use the most restrictive channel direction that will work for your needs
Document channel ownership: Make it clear which component is responsible for creating, writing to, and closing each channel
Use consistent naming: Consider using suffix naming patterns like inputCh and outputCh to make the flow clear
Return receive-only channels: When a function creates and returns a channel, return it as receive-only if clients only need to receive from it
Accept send-only or receive-only parameters: Functions should specify which direction they need for channel parameters

Summary#

Channel direction provides type safety for channel operations
There are three types: bidirectional, send-only, and receive-only
Bidirectional channels can be converted to directional, but not vice versa
Only senders should close channels
Using channel direction makes code more type-safe and self-documenting
Channel direction is a powerful way to enforce communication patterns

In the next lab, we'll explore the concept of channel ownership, which complements channel direction by establishing guidelines for which components should create, write to, and close channels.

Channel Direction

Why Specify Channel Direction?#

Channel Direction Types#

Syntax#

Channel Direction Conversion#

Example: Using Channel Direction#

Common Patterns with Channel Direction#

The Generator Pattern#

The Worker Pattern#

The Message Relay Pattern#

Closing Directional Channels#

Using Type Assertions with Directional Channels#

Best Practices#

Summary#

Your Progress