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
Add abi.encodeError
similarly to abi.encodeCall
#14287
Comments
This issue has been marked as stale due to inactivity for the last 90 days. |
This issue has been marked as stale due to inactivity for the last 90 days. |
This issue has been marked as stale due to inactivity for the last 90 days. |
still relevant |
In either case, in the future we consider allowing to declare local variables of error type and being able to pass them along. As in:
or in the latter version something more like
(which works much less gracefully until we switch to postfix types and is also less ideal until we have polymorphic functions) In either case, the (only possible) semantics of these would be for the variable And thus, the saner way to access the abi-encoding of an error would be by mere explicit conversion, as in Now we can consider going the easier route of |
Please note that 10 months happened between the issue was submitted and the PR was oppened. There was plenty of time to discuss, but discussion honestly doesn't happen (as visible in this thread) until somone actually starts pushing the thing by implementing it. At least that is how it feels from the outside world. Having a |
Well, I appreciate that it's frustrating if issues go unanswered, but we get a huge volume of incoming feature requests, a lot of them reasonable in the first instance, but we have limited resources to address all of them (and the first obvious choice is often not the best longer-term, so even seemingly innocuous requests require some careful consideration - we have a lot of unfortunate inconsistencies in the language due to moving ahead more prematurely in the past). In general, there is a lot of weak points and missing features in the language currently, and it's long-term not viable to address them safely one by one in the current manner, hard-coded in the compiler, which is why our main focus currently is to work on the longer-term evolution of the language, which will involve a standard library for which we envision a well-defined community improval process to generally mitigate this issue. This feature request here is, technically, clearly a case that would better be handled that way, if that was already possible. Now, of course, this won't happen quickly and we also need to continue to develop the language meanwhile - examples are #14913, which was the most requested feature in the past language survey, and now also high-level transient storage support. That being said, it's of course not tenable if the outside impression is that feature requests are ignored and discussion has to be forced. The forum was partially meant to mitigate this to allow the community to mobilize broader support for individual feature requests to allow us a more informed view on community demand for features prior to us transitioning to a formal process for a standard library - but that so far has not really lived up to expectations, so we'll try to find and define additional means for this, so bear with us on that. |
Abstract
Using
abi.encodeCall
for encoding errors fails with errorIt would be nice to have a
abi.encodeError
that works similarly toabi.encodeCall
, but for custom errors.Motivation
Both functions and error include a
.selector
getter that returns thebytes4
"signature". In the case of a function selector, this can be used, along withabi.encodeWithSelector
to generate the bytes corresponding to a function call. Similarly,abi.encodeWithSelector
can be used to encode a custom error.abi.encodeCall
is a safer alternative that verifies the type and number or arguments at compile type. Whileabi.encodeCall
works well with functions, it does not currently support errors.Being able to generate the bytes corresponding to custom errors can be particularly usefull for testing with Foundry.
Specification
Given a custom error
Enable the syntax
abi.encodeError(SomeErrorName, (arg0, arg1, arg2, arg3));
that returns the same as
with the same type checking as
abi.encodeCall
Backwards Compatibility
None. This is introducing a new syntax that doesn't conflict with existing ones.
The text was updated successfully, but these errors were encountered: