-
Notifications
You must be signed in to change notification settings - Fork 30.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
test: return frozen function from common.must[Not]Call #43825
Conversation
Affects `mustCall()`, `mustCallAtLeast()`, `mustNotCall()`, and `mustSucceed()`.
On first glance, this seems more surprising than useful to me. |
Some additional elaboration on the purpose here: this PR is partially a continuation of #43196 and attempt to work around its inability work with functions.
This is very implicit so I'm not 100% sure about this idea; feel free to block if it sounds dangerous or completely useless. |
I agree, the name doesn't give any indication that this might happen, and it feels weird that there is no way of disabling it. |
Not really seeing the usefulness here. |
Closing as unneeded. Adjustments to |
I wonder if it would make sense to return frozen functions from
mustCall()
,mustCallAtLeast()
,mustNotCall()
andmustSucceed()
.Pros: implicit check that functions are never mutated, with no code cost.
Cons: impossible to monkey-patch them in tests.