Yoshiya Hinosawa

Note: This increases the amount of calculation because `unit` and `rate` are calculated at each rendering. However this also makes the output more correct because now we allow to change...

I'm generally in favor of the idea. It looks useful in several places, and also this is aligned to the design of builtin map methods (such as `map`, `filter`, `forEach`,...

> Two methods: shuffle and toShuffled (similar to built in methods reverse and toReversed, sort and toSorted, etc.): one for updating the array in place and the other for returning...

`@std/expect` generally tries to be compatible with jest APIs (and we currently don't have plan to make `@std/expect` and `@std/testing/mock` compatible). So the idea of this issue is to implement...

I'm not in favor of this change. The change doesn't seem worth the performance degradation.

This is no longer necessary as we chose to use FakeTime for reducing flakiness. https://github.com/denoland/std/pull/6686

I'm not in favor of this change as the added complexity is not small, but this doesn't support any new practical scenario.

As @BlackAsLight pointed, this introduces a new bugs related to start method. Because `end` method doesn't reset `this.#intervalId` to undefined, the second `start` call doesn't print the progress anymore. Also...

> lots of web apis use the convention of class initialization as a setup and a method to start the process ([MutationObserver.observe()](https://developer.mozilla.org/en-US/docs/Web/API/MutationObserver/observe), [SpeechRecognition.start()](https://developer.mozilla.org/en-US/docs/Web/API/SpeechRecognition/start), etc.) There are also APIs which start...

Also alignment to the web platform api shouldn't be the goal in my view. It should be only supplementary for design decisions when there are equally possible designs. If the...