Latest Results
Implement `__mem_rep_eq` intrinsic (#7697)
## Description
This PR introduces a new `__mem_repr_eq` intrinsic for comparing memory
representation of types, and removes the existing `__runtime_mem_id` and
`__encoding_mem_id` intrinsics.
We decided to introduce `__mem_repr_eq` to mitigate the following issues
we had with existing intrinsics:
- `mem_id`s were `u64` values computed using `DefaultHasher` whose
results are not guaranteed to be stable across different runs of the
same Sway compiler or being same on different target architectures.
- even if we switched to a stable hasher, hashing to `u64` was not
giving a strong no-collision guarantee. A hash collision between
different, e.g. runtime and encoding representation, would in case of
false positives result in wrong encoding or decoding.
The `__mem_repr_eq` is defined as:
```sway
__mem_repr_eq<T>(repr_a: str, repr_b: str) -> bool
```
It returns `true` if the memory representation `repr_a` of the type `T`
is equal to its memory representation `repr_b`, assuming `T` has both
memory representations. If `T` does not have any of the representations
`repr_a` or `repr_b`, returns `false`.
The valid values for `repr_a` and `repr_b` are `"runtime"`,
`"encoding"`, and `"hashing"`:
- `"runtime"` is how the type is represented inside the VM's memory.
This is the Sway runtime memory representation (e.g., struct fields are
aligned to word boundaries, arrays are packed, etc.). This memory
representation is defined for every type.
- `"encoding"` is the packed memory representation of a type, as defined
by the canonical ABI encoding. Not all types have a canonical ABI
encoding defined, e.g., dynamic types like `Vec` or `raw_slice`. In that
case, `"encoding"` never compares equal to any other memory
representation, __including to itself__.
- `"hashing"` is the packed memory representation of a type, as defined
by the canonical hashing introduced in #7695. Not all types have a
canonical hashing defined, e.g., dynamic types like `Vec` or
`raw_slice`. In that case, `"hashing"` never compares equal to any other
memory representation, __including to itself__.
To test if a type `T` has `"encoding"` or `"hashing"` memory
representation defined, compare that representation to itself. E.g.:
`let has_encoding_repr = __mem_repr_eq<T>("encoding", "encoding");`
`repr_a` and `repr_b` must be compile-time constant `str`s, whose values
are one of `"runtime"`, `"encoding"`, or `"hashing"`. The constant
`str`s never end up in the bytecode.
Additionally, the PR moves existing E2E intrinsics tests that were not
in the `language/intrinsics` into `language/intrinsics`.
## Breaking Change
The old `__runtime_mem_id` and `__encoding_mem_id` intrinsics are
removed. The code that is using them must switch to the new
`__mem_repr_eq`.
## Checklist
- [x] I have linked to any relevant issues.
- [x] I have commented my code, particularly in hard-to-understand
areas.
- [x] I have updated the documentation where relevant (API docs, the
reference, and the Sway book).
- [ ] If my change requires substantial documentation changes, I have
[requested support from the DevRel
team](https://github.com/FuelLabs/devrel-requests/issues/new/choose)
- [x] I have added tests that prove my fix is effective or that my
feature works.
- [x] I have added (or requested a maintainer to add) the necessary
`Breaking*` or `New Feature` labels where relevant.
- [x] I have done my best to ensure that my PR adheres to [the Fuel Labs
Code Review
Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md).
- [x] I have requested a review from the relevant team or maintainers. Latest Branches
0%
ironcev/rollout-block-is-entry 0%
ironcev/mem-repr-id-intrinsics 0%
xunilrj/fix-sroa-load-multi-blocks © 2026 CodSpeed Technology