/cc @rsc

@snadrus What do you recommend instead?

The GC behavior is clearly documented, and the alternative involves not using time.After at all. But still seems useful to have an example for time.After.

The risk is with "select" statements. Adding that to the documentation could help.

An example could have goroutine blocking: https://play.golang.org/p/0eUOnvITpcg

@snadrus your example would be better written with time.Sleep.

There are many safe uses of time.After. And most such uses will be in select statements.

It's true that if you have many calls to select statements that use time.After with a long duration, and if those select statements normally terminate quickly, then you will steadily accumulate memory dedicated to timers. And that is why the documentation already says "The underlying Timer is not recovered by the garbage collector until the timer fires. If efficiency is a concern, use NewTimer instead and call Timer.Stop if the timer is no longer needed."

But it's perfectly fine to use time.After if you don't run the select statement many times, or if the duration of the time.After is short, or if the code often times out via time.After rather than because data is sent on one of the other channels.

That's quite a list of undocumented gotchas. If you're content with it, then I suppose we can close this bug.

I only count a single gotcha, and it is documented.

That single root cause is 3 "use" gotchas;

• Used too frequently
• Used with too long a delay vs use
• Used in places with "too few" timeout failures

In order to have a real problem, all three must be true.