-
-
Notifications
You must be signed in to change notification settings - Fork 177
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
to panic or not to panic, that is the question #170
Comments
Sure, pull request invited. |
maybe you will rethink if you really catch the panic in New() and change the length to 0 under the hood. Perhaps it's generally better to propagate the runtime panics unaltered. You can save some cpu cycles in the hot path and you panic anyway e.g. in |
@gaissmai Yes, although that would have to be a major release and we should carefully document that the constructor may panic. Pull request invited. |
hmm, I'm not sure whether this requires a major release. The public interface does not change, only the internal behavior:
I would also leave out the test on request for comment |
This is a big deal. For now there is no way function can panic from user perspective, but changing this behaviour without major version bump can lead to potential unexpected panics in runtime for users. |
But there are other functions that trigger a panic for the same reason, i.e. if you have specified a |
and by the way, the current docstring for |
New()
intercepts a panic indefer()
ofmakeslice
and at least for this reason New() is not inlineable and therefore the slice always escapes to the heap. Currently I work around this withFrom(buffer)
but would it also be possible that aMustNew(int)
is possibly inlineable if it just propagates the panic.The text was updated successfully, but these errors were encountered: