proposal: testing: make Testing return a compile-time constant #60772
Comments
|
As I noted above, the rebuild is the cost. It is unclear to me what the gain is exactly. The use case mentioned in #60737 of using testing.Testing as a kind of "enable extra, slow debugging checks in crypto packages but have it compile away completely in non-tests" seems like a mistake. It would mean that crypto is slow in everyone's tests everywhere, not just in the crypto tests, and it would also make it impossible to benchmark crypto at its full speed. Given that the use case is a mistake, making it compile away in non-test code does not seem like an important benefit. Is there some other important benefit to be had by making Testing inline to a constant result? |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
#60737 suggests adding
const Testing bool = ...to package testing, unaware of #52600 that addedfunc() Testing bool.This proposal is a replacement for #60737 to discuss whether the new API should return a compile-time constant (right now the result is filled in at link time), so that packages can compile differently when being built as a dependency of a test.
Specifically, package testing would itself build differently when built as a dependency of a test versus a non-test binary, and then any packages that import "testing" in non-test code would then also have to rebuild. So if A imports B imports C imports testing, and A also imports D, and we are building A's test, we have to rebuild testing, C, B for A's test, but not D.
The rebuild is the only cost here. The potential problems with abuse of testing.Testing are the same either way.
The text was updated successfully, but these errors were encountered: