Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
ABI: enums, structs and timestamps #50
Add the following new elementary types to the ABI:
At any point in an interface definition where an elementary type is allowed, the following is also allowed:
Such a type is called an "enum" and the identifiers
Structs allow several values to be grouped together. This is especially useful if arrays of structs are created. If you look closely, you notice that the set of return values or arguments is already a struct now and the notation will be consistent with this proposal.
Change to function signatures as needed for function identifiers
As function signatures omit parameter names and only specify their types, and struct types should be a generalisation of a list of parameters / return parameters, the following change is proposed:
At any point where a type is allowed, a list of types in the from
The function takes an array of 20 objects, each of which is of the following type:
Note that this notation is (hopefully) bijective.
Structs are actually already part of the encoding specification, hidden in this comment. The gist is that the way arrays are encoded does not rely on the fact that the encoding of every element of the array is the same, so we can encode structs in just the same way as we encode arrays. This means that the encoding of a struct with only fixed-size types is the concatenation of the encodings of its elements. If there are dynamic types, their dynamic part is added at the end and the offset to the dynamic part is calculated from the start of the struct. This means that the offset to the string data is computed in a different way for
referenced this issue
Jan 16, 2017
@VoR0220 suggested that the types of json fields should be fixed, i.e.
In the above example,
I would very much prefer it if
It is unclear to me why
@Souptacular What, if anything, can be done to get this EIP moved forward? It doesn't seem to have much/any active discussion going on, but has been sitting for months.
The lack of structs as part of the ABI combined with 16 variable stack limit is really hurting Augur's port to Solidity from Serpent.
@MicahZoltu it maps to the
@chriseth Would it make sense to create an EIP PR for the struct part of this so that it can be tracked and eventually merged without having to wait on the other aspects of this EIP? In general I'm a fan of small targeted EIPs over monolithic bucket EIPs like this.
@MicahZoltu yeah, we should probably write that up. Here is the complete specification that is currently being implemented by Solidity: https://solidity.readthedocs.io/en/develop/abi-spec.html