<pre class="notranslate">Consider special-casing timer channels created with time.Ticker and time.After.
Namely, such chans need to contain next fire time and period. Then receive from such
looks like:

func chanrecv(c *Hchan) {
  ...
  if c.isTimeChan {
    for {
      next := c.nextTime
      if next == -1 {
        // already fired one-time timer
        blockForever()
      }
      newTime := -1
      if c.period != 0 {
        newTime = next + c.period
      }
      if CAS(&amp;c.nextTime, next, newTime) {
        wait := next - now
        if wait &gt; 0 {
          sleepFor(wait)
        }
        return
      }
    }
  }
  ...
}

This has several advantages:
1. No need to stop timers. If nobody waits on a timers, it's just a normal heap object
that can be garbage collected.
2. Faster operation for both blocking and non-blocking case.
3. Faster selects involving time chans.
4. Can combine time.Ticker/After into a single allocation.</pre>
<p dir="auto">After almost a decade, I have <strong><em>finally</em></strong> implemented <a class="issue-link js-issue-link" data-error-text="Failed to load title" data-id="51288843" data-permission-text="Title is private" data-url="https://github.com/golang/go/issues/8898" data-hovercard-type="issue" data-hovercard-url="/golang/go/issues/8898/hovercard" href="https://github.com/golang/go/issues/8898">#8898</a>, special-casing the channels used for timers (or maybe the timers used for channels) so that the timers are not in the timer heap when there are no channel operations pending on them. This means that the channels and timers can be GC'ed once they are no longer referenced, without having to wait for a timer to expire or explicitly Stop the timer. (By timer here I mean the data structure used by time.After, time.NewTimer, and time.NewTicker.)</p>
<p dir="auto">This raises a question: do we want to guarantee that all future versions of Go will provide this behavior, so that code can rely on not needing to call the Stop methods? I think we probably should make that guarantee.</p>
<p dir="auto">I propose we land my CL and document that After can be used without concern for GC and that NewTimer and NewTicker can be used without concern for deferring Stop just for GC. At the moment the doc comment for After describes the problem and basically says "don't use this function a lot". If we accept this proposal, we can remove that text. NewTimer and NewTicker do not mention needing to call Stop, although it is implied by After's doc comment. If we accept this proposal, we can document that Stop is not necessary for GC, so that people can stop calling Stop.</p>