Richard Feldman

> (And assuming that `Expect.within` for floats is always a bad idea, this is a PATCH change that will break a lot of tests.) I assume this was supposed to...

> It's more likely that the dev has that part of the code base in their working memory right when they write the tests, than when they go in to...

> We should consider the performance hit as well, though. In 0.19 we should be getting `Kernel` access (for `try` / `catch` so we can translate exceptions into test failures,...

> The `\xA0` parsing looks like a compiler bug to me, or a really strong feature request. That's a good point. Given that Evan rewrote the parser for 0.19, this...

> this will be solved by removing octal and hexadecimal escape sequences, in favour of unicode escape sequences \u[a-fA-F0-9]{4}. So \xA0 would become \u00A0 which takes case of the parsing...

This is interesting! To set expectations, I don't think we should work on this until after the `4.0.0` release. That release will be breaking and is already hefty in scope,...

As an aside, this seems like it's more scoped to test runners, so I might open an issue on https://github.com/rtfeldman/node-test-runner and/or other runners instead of here.

> First one is determinism; a timeout-based implementation will not be deterministic. This might not seem like a problem at first, but debugging failed fuzz test runs in a non-deterministic...

As to these design questions, I think the answer to all of them is "revisit once someone has a specific motivating use case." Until then this is interesting, but not...

Wow, really interesting perspective! I've heard positive things from others, but clearly there is another side to this story. 🤔