feat: support evm address #668
Conversation
|
Needs forc update |
| // ANCHOR_END: evm_address | ||
|
|
||
| impl EvmAddress { | ||
| fn clear_12_bytes(bytes: [u8; 32]) -> [u8; 32] { |
There was a problem hiding this comment.
Since it's private might save space and just make it a fn instead of an associated fn.
Goes without saying that it doesn't make any difference functionally.
There was a problem hiding this comment.
I like that it's an associated function since it's a very specific "utility", it would be weird to see it implemented outside this context.
| // ANCHOR_END: evm_address | ||
|
|
||
| impl EvmAddress { | ||
| fn clear_12_bytes(bytes: [u8; 32]) -> [u8; 32] { |
There was a problem hiding this comment.
I like that it's an associated function since it's a very specific "utility", it would be weird to see it implemented outside this context.
| {{#include ../../../packages/fuels/tests/bindings.rs:evm_address_arg}} | ||
| ``` | ||
|
|
||
| > **Note:** when creating an `EvmAddress` from `Bits256`, the first 12 bytes will be cleared because an evm address is only 20 bytes long. |
There was a problem hiding this comment.
Explain the choice of clearing the leftmost ones. If it is a deliberate choice (ie not based on spec), then this choice should be stated clearly ("We chose the convention of clearing the leftmost bytes").
There was a problem hiding this comment.
The choice was made based on the Sway implementation of the same type. I find this a bit tricky to comment since we had a task to specifically remove all mentions of sway.
Co-authored-by: iqdecay <victor@berasconsulting.com>
Closes #661
The
EvmAddressis implemented equivalent to the Sway type, as a wrapper overBits256. And just like in Sway, the first 12 bytes are zeroed out when it is instantiated fromBits256.Encoding/decoding this type is treated as a struct with a single
Bits256field.