@gopherbot, add labels Go2

I personally believe that time.Tick is fine, especially because it is clear (at least in my eyes) that the ticker never stops. The documentation also clearly points out the leak.

However I can understand it being deprecated, especially since there is a concise alternative.

Well, despite its shortcomings which are clearly described in the documentation, time.Tick has always been intended as a convenience function for time.NewTicker as both have been in the standard library from the start.

That being so I can't really see the point in deprecating it now as it will mean that a vast amount of code which currently works fine will eventually need to be changed.

To be clear: deprecating the function does not necessarily require that we remove it entirely. (We could leave it deprecated forever, or only disallow references to it from within modules that specify go 1.N.) See #30639.

Thanks for that link as I'd always thought that deprecating something meant that you shouldn't use it as it's eventually going to be removed.

Having said that, there's stuff in Java which has been deprecated for years and there's still no sign of it being removed.

Whatever deprecation means, I'm still not really in favor of the proposal as time.Tick is occasionally useful.

I will elaborate on the reason I opened that issue. I've used go doc time and picked time.Tick() for a client connection handler that should free the timer after the client has been disconnected and I assumed that it will free it automatically. It was a rookie mistake and from now on I use go doc -all <pkg> | less, instead. If the function name was TickForever(), I might have given it more thought.

I was convinced that I am not the only one who made that mistake or just read convenience wrapper and did not read further. So I have searched GitHub and googled for code that uses time.Tick() and sure enough I found some cases.

Here is a list of examples, which I believe are problematic, since there is an option to stop or break the loop, yet the ticker cannot be freed:

• https://github.com/golang/sys/blob/master/windows/svc/example/service.go#L23
• https://github.com/Netflix/hal-9001/blob/master/hal/periodic.go#L134
• https://github.com/pydio/cells/blob/master/common/service/utils.go#L28
• https://github.com/izikaj/iziproxy/blob/master/server/tcp_handle_signals.go#L49
• https://github.com/gocraft/health/blob/master/aggregator.go#L22
• https://github.com/GoogleCloudPlatform/compute-image-tools/blob/master/daisy/step_create_instances.go#L54
• https://github.com/rs/xstats/blob/master/statsd/statsd.go#L79
• https://github.com/flynn/flynn/blob/master/controller/scheduler/discoverd.go#L32

Cases that are not problematic, since the executable will exit and the runtime will stop the timer eventually, but are still misused and leak resources:

• https://github.com/cockroachdb/cockroach/blob/master/pkg/storage/client_raft_test.go#L1390 (do their leaktest even work?)
• https://github.com/solo-io/go-utils/blob/master/testutils/helper/curl.go#L61
• https://github.com/odeke-em/youtube-popular-bot/blob/master/cmd/youtube-popular-bot/main.go#L110
• https://github.com/influxdata/influx-stress/blob/master/cmd/insert.go#L119

I've found those examples using Google search string: intext:"time.Tick(" ext:go site:github.com

This is closely related to #19702 (see #19702 (comment) and its reply), in that it addresses an empirical mismatch between users' assumptions about garbage collection for time.Ticker and the actual GC behavior as implemented.

Perhaps not exactly what this issue is about, but I want to mention https://golang.org/cl/214999, which is an attempt to garbage collect unreferenced tickers. It may be possible to get that CL into 1.15.

That changeset is nice, but it just removes the symptoms and it also bloats the runtime, just like if we add garbage collection of goroutines.

Now that I am thinking that it's not just an issue about time.Tick(), it may be better if we use static analysis to check if the goroutine can exit without stopping a Ticker.

PS. I am not sure if my proposal is still relevant.

Bloating the runtime is a valid complaint, but you write "removes the symptoms" as though that is a bad thing. It seems to me that removing the symptoms is equivalent to removing the problem.

Ok, you are right.

I guess we can close the proposal, since the patchset solves the problem.

Proposal withdrawn.