No, it definitely does.
Not according to the official documentation. There the output definition exists only in the JSON description of the ABI, not in the bytecode.
If you want to prove once and for all that you are correct, please compile an example contract and demonstrate how to recover the return types from the bytecode.
[the JSON is] accessible to users of the interface at their compile-time.
Not in all cases. We cannot decode future contracts that are yet to be designed.
Perhaps the words you donât know are encoding and decoding.
The input types are encoded with a keccak256 hash and a truncation. There is no way to decode that one way mapping.
The output types are only defined in the off-chain JSON file and are neither automatically encoded nor decoded.
Itâs not an EIP. Itâs an ERC.
I am indifferent. For the moment we will follow SamWilsnâs naming decision
It canât when a contract doesnât implement your method.
Correct. This would be an optional standard, If ERC165 isnât followed then the return types will not even be queried.
It canât when a contract implements the method incorrectly or maliciously.
Agreed. Automated complier integration would be a nice way to reduce this risk. But not essential for the EIP.
A better way to return arbitrary data would be to return the encoded type with the arbitrarily-typed data.
Not ideal. For example, that doesnât stop a uint256 being mistaken for an address. It also makes adoption compulsory where as my proposal is optional.
Your 1-byte type definitions are good.
Great. Thatâs the real meat of the proposal that I would like the community to accept/discuss.
I donât like that composite types can be arbitrarily long, but so can Solidity types.
Me neither, it stops everything fitting nicely into an efficient bytes32 storage space. It is what it is. Iâve swapped to a bytes array because if an edge case exists, someone is bound to hit it at some point.
Does solidity have a complex number type?
There is a stagnant EIP. Iâm taking the liberty of reserving a placeholder for them.