How do I iterate over a go time.Tick channel?

I'm having difficulty using time.Tick. I expect this code to print "hi" 10 times then quit after 1 second, but instead it hangs:

ticker := time.NewTicker(100 * time.Millisecond)
time.AfterFunc(time.Second, func () {
	ticker.Stop()
})

for _ = range ticker.C {
	go fmt.Println("hi")
}

https://play.golang.org/p/1p6-ViSvma

Looking at the source, I see that the channel isn't closed when Stop() is called. In that case, what is the idiomatic way to iterate over the ticker channel?

You're right, ticker's channel is not being closed on stop, that's stated in a documentation:

> Stop turns off a ticker. After Stop, no more ticks will be sent. Stop does not close the channel, to prevent a read from the channel succeeding incorrectly.

I believe ticker is more about fire and forget and even if you want to stop it, you could even leave the routine hanging forever (depends on your application of course).

If you really need a finite ticker, you can do tricks and provide a separate channel (per ThunderCat's answer), but what I would do is providing my own implementation of ticker. This should be relatively easy and will give you flexibility with its behaviour, things like what to pass on the channel or deciding what to do with missing ticks (i.e. when reader is falling behind).

My example:

func finiteTicker(n int, d time.Duration) <-chan time.Time {
	ch := make(chan time.Time, 1)
	go func() {
		for i := 0; i < n; i++ {
			time.Sleep(d)
			ch <- time.Now()
		}
		close(ch)
	}()
	return ch
}

func main() {	
	for range finiteTicker(10, 100*time.Millisecond) {
		fmt.Println("hi")
	}
}

http://play.golang.org/p/ZOwJlM8rDm

I asked on IRC as well, at got some useful insight from @Tv`.

Despite timer.Ticker looking like it should be part of a go pipeline, it does not actually play well with the pipeline idioms:

> Here are the guidelines for pipeline construction:
>
> - stages close their outbound channels when all the send operations are done.
> - stages keep receiving values from inbound channels until those channels are closed or the senders are unblocked.
>
> Pipelines unblock senders either by ensuring there's enough buffer for all the values that are sent or by explicitly signalling senders when the receiver may abandon the channel.

The reason for this inconsistency appears to be primarily to support the following idiom:

for {
    select {
    case <-ticker.C:
        // do something
    case <-done:
        return
    }
}

I don't know why this is the case, and why the pipelining idiom wasn't used:

for {
    select {
    case _, ok := <-ticker.C:
        if ok {
            // do something
        } else {
            return
        }
    }
}

(or more cleanly)

for _ = range ticker.C {
    // do something
}

But this is the way go is