How would you feel about using functional options instead of...string? An alternative to having this convenience function would be to accept the following signature:

NewTicker(d time.Duration, f func() error, opts ...Option) and you'd pass itclock.WithContext(ctx) or `clock.Tags("tag1", "tag2") as options.

I think this could result in a slightly cleaner and more flexible API, as well as the added verbosity/explicitness can help with code reads (i.e. "what are these strings?").

In this scenario, I imagine the return signature ofNewTicker could include all three methodsStop,Reset andWait.

Firstly, maybe "ContextTicker" isn't the best name. It's not a ticker that optionally takes a context, it's a ticker calls the functionf on the ticks, rather than just sending the ticks to a channel. Sort of likeAfterFunc is a special timer that calls a function. "TickerFunc"?

Secondly, the idea is to include tags onevery call in theclock interface, and all the timer/ticker calls as well. With the exception of this ContextTicker/TickerFunc, the idea is to verbatim replicate the functionality of thetime package, not enhance it. So, I literally cannot think of another option we'd want other than tags, and even if I could, it's unlikely to apply toevery call, so adding it to a genericOption interface would muddy the waters. I think variability is actually a downside in this case, and we should keep it simple.

Lastly, I'm not a fan of the verbosity ofclock.Tags("tag1"). The signature saystags ...string, so I feel like that's clear enough once you jump to the definition.