ENUM as ABI type

[alexvandesande]

A FAQ on the solidity docs:

If I return an enum, I only get integer values in web3.js. How to get the named values?
Enums are not supported by the ABI, they are just supported by Solidity. You have to do the mapping yourself for now, we might provide some help later.

Enums would actually very useful types to be exposed on the ABI, specially for auto generated interfaces on the wallet and on abi2html, for example. On the read side, properties could be exposed as words instead of meaningless integers. On the execute side, enums could be rendered as drop down or radio boxes.

This would make interface creation easier.

[chriseth]

Any ideas for the notation? As we kind of settled for anonymous structs in the other EIP, enums should also be anonymous.
Brainstorming:
[Val1,Val2,Val3]
(Val1|Val2|Val3)

[alexvandesande]

Well it's an array of strings right? Shouldn't it be [ 'value 1', 'value 2', ...] ?

[chriseth]

I would say that it is rather a list of identifiers instead of strings. Furthermore, I think it would be a good idea to differentiate enums from a tuple/struct types.
If enum or similar keywords are not used, the common way to notate such types is using |:
https://en.wikipedia.org/wiki/Sum_type

[tgerring]

On first glance, [Val1,Val2,Val3] appears to be a collection of objects. To avoid confusion with that common notation, I'd personally prefer the pipe-delimiter or something that is difficult to confuse with another type.

[axic]

As we kind of settled for anonymous structs in the other EIP, enums should also be anonymous.

Which other EIP are you referring to? I've only found the timestamps prior to this one.

Would it be any harm making it more explicit such as enum(Val1|Val2|Val3) or enum(Val1,Val2,Val3) ?

Just trying to avoid a situation where new types will have a weird notation to avoid collisions.

[chriseth]

I was referring to this proposal here: #21

My reasoning behind not using explicit enum and struct strings was that names are always hard to get consensus on and different languages might use different names for these type constructs. You are right that explicit enum and struct prefixes avoid collisions (and also makes it easier to parse), but having to use struct at the inner level and not at the outermost level makes it a bit less elegant.

[axic]

I don't think it would hurt to have struct written out on all levels, but as it is a more frequent construct I can understand if that won't be the case.

However, usually enum is less frequently used and I think it makes sense to be explicit in that case.

[github-actions]

There has been no activity on this issue for two months. It will be closed in a week if no further activity occurs. If you would like to move this EIP forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review.

[github-actions]

This issue was closed due to inactivity. If you are still pursuing it, feel free to reopen it and respond to any feedback or request a review in a comment.