Closed wtdcode closed 4 months ago
We do not intend these values to be (de)serialized, as they do not correspond to any standard data forma. We aren't really interested in pushing a new standard. For now, all of these types should be in-memory only
Closing as not planned
We do not intend these values to be (de)serialized, as they do not correspond to any standard data forma. We aren't really interested in pushing a new standard. For now, all of these types should be in-memory only
Closing as not planned
I can't understand. It's mostly harmless.
Note ethabi
also has these. If alloy
is intended as an alternative to ethers-rs
, it should also enable these derives, no? See https://github.com/gakonst/ethers-rs/issues/2667. Not having these derives prevents migration from ethers-rs
to alloy/core
.
Even just "in memory`, this enables it to represent in other format.
For tracking pupose, https://serde.rs/remote-derive.html also doesn't work:
error[E0277]: the trait bound `DynSolValue: Deserialize<'_>` is not satisfied
--> -:21:15
|
21 | Tuple(Vec<DynSolValue>),
| ^^^^^^^^^^^^^^^^ the trait `Deserialize<'_>` is not implemented for `DynSolValue`, which is required by `Vec<DynSolValue>: Deserialize<'_>`
|
= help: the following other types implement trait `Deserialize<'de>`:
<bool as Deserialize<'de>>
<char as Deserialize<'de>>
<isize as Deserialize<'de>>
<i8 as Deserialize<'de>>
<i16 as Deserialize<'de>>
<i32 as Deserialize<'de>>
<i64 as Deserialize<'de>>
<i128 as Deserialize<'de>>
and 493 others
= note: required for `Vec<DynSolValue>` to implement `Deserialize<'_>`
Motivation
Derive
Serialize/Deserialize
if possible (withserde
dep).Solution
See diff.
PR Checklist