I'm concerned that this might be a bit of a footgun, since correct behavior really depends on whether there are any other goroutines also reading from the channel. If you know for sure that there are no other goroutines reading, then the code in https://golang.org/pkg/time/#Timer.Stop is correct:

    if !t.Stop() {
        <-t.C
    }

If there are other goroutines reading from the channel, then it's not completely obvious what the right code is. At least, it's not obvious to me.

Just to be very clear, there is no need to read from the channel after calling t.Stop in the general case. The only time this case arises is if you want to keep using the timer, presumably by calling t.Reset.

Note that

	if !t.Stop() {
		select {
		case <-t.C:
		default:
		}
	}

is not entirely reliable today (with or without concurrent receivers) due to #37196.

(If that issue is addressed, then that pattern will be correct even in the presence of concurrent receivers.)

I'm not sure that StopAndClear has any possible benefit. At first it might seem like it does, but the details of concurrency and channels and goroutines make the situation more subtle than it first appears.

If another goroutine is waiting to read a value from a channel, then t.StopAndClear would race with it. The t.StopAndClear call could return but then the other goroutine could still - in physical wall time - receive the value afterward, due to scheduling delays. You need some explicit synchronization with the other goroutine to make sure that processing of the receive is over. But if you are going to that trouble (or you don't have the other goroutine) then t.Stop is sufficient.

So t.StopAndClear doesn't end up being any easier to use than t.Stop.

The one thing t.StopAndClear could do is solve the "time value waiting in a buffered channel" issue. But if we want to fix that, we should probably just make t.Stop do that part, instead of adding new API. That's #37196 (thanks Bryan), which we can discuss over there.

Based on the discussion above, this seems like a likely decline.
(Looks like I aded the Proposal-FinalCommentPeriod label incorrectly last week; the project status "Active" was correct.)

Yeah it looks like I was confused by the documentation - it's nice to know that we don't need to clear channels to prevent leaks.

No change in consensus (and retracted), so marking declined.