Add Timer.measure methods

[FranzBusch]

Motivation

This PR supersedes #135. The goal is to make it easier to measure asynchronous code when using Metrics.

Modification

This PR does:

• Deprecate the current static method for measuring synchronous code
• Add a new instance method to measure synchronous code
• Add a new instance method to measure asynchronous code

[FranzBusch]

@swift-server-bot test this please

[Lukasa]

@swift-server-bot add to allowlist

[gjcairo]

LGTM, just a nit about docs.

[gjcairo]

Nit: the doc for this method and the non-async version don't match. Maybe remove the last bit to match that one, since we're defaulting the clock param anyways?

Suggested change

	/// Convenience for measuring duration of a closure with a provided clock.
	/// Convenience for measuring duration of a closure.

[FranzBusch]

@swift-server-bot test this please

[FranzBusch]

@fabianfett @simonjbeaumont @czechboy0 I dusted off this PR again and brought up to the latest Swift standards. If you could take another look that would be great.

[FranzBusch]

@czechboy0 To address your feedback I removed the deprecation. This will allow current adopters or adopter with platform requirements to stay with the existing API.

[czechboy0]

To address your feedback I removed the deprecation. This will allow current adopters or adopter with platform requirements to stay with the existing API.

Thanks, Franz. And the second question - are we okay only offering this new method to packages with the raised OS requirements?

[FranzBusch]

Thanks, Franz. And the second question - are we okay only offering this new method to packages with the raised OS requirements?

Yes, I think that's fine. The other method exists and the intention of the new one is to take advantage of Clock.

[czechboy0]

Yes, I think that's fine. The other method exists and the intention of the new one is to take advantage of Clock.

Right, it's not a big inconvenience - it might just be confusing that the instance method requires a newer OS (because it uses Clock), but the static method doesn't. We could add a @_disfavoredOverload instance method variant that doesn't use Clock? Up to you.

[FranzBusch]

Right, it's not a big inconvenience - it might just be confusing that the instance method requires a newer OS (because it uses Clock), but the static method doesn't. We could add a @_disfavoredOverload instance method variant that doesn't use Clock? Up to you.

I get your point but I really don't think we should add those. Clock is the way forward and there is the existing static method that provides an escape hatch. We can always add it is somebody asks for it.