Extend enum support beyond strings with the unit type

[Braqzen]

Enums are documented to act as strings.

I don't know if that's a good approach but at least the documentation is limited to enums that only use unit types.

We should extend enum support beyond the unit type and document its usage.

[ra0x3]

@Braqzen

• This one is tricky because it's a bit of a clash between Sway and GraphQL (feel bad for us 🥲)
• GraphQL enums are just flat references (or labels)
• While Sway enums can be flat references (labels) or actual complex types (like a struct-ish)
• We definitely need to document why we only support enums as flat labels
• It wouldn't be impossible for us to make enums just union types in GraphQL, and stop treating them as labels
  • However this would just require some work that we unfortunately don't really have bandwidth for :(

[Braqzen]

@Braqzen

• This one is tricky because it's a bit of a clash between Sway and GraphQL (feel bad for us 🥲)
• GraphQL enums are just flat references (or labels)
• While Sway enums can be flat references (labels) or actual complex types (like a struct-ish)
• We definitely need to document why we only support enums as flat labels

• It wouldn't be impossible for us to make enums just union types in GraphQL, and stop treating them as labels

  • However this would just require some work that we unfortunately don't really have bandwidth for :(

That's unfortunate because logging types like the Identity (an enum of struct variants) is a very common operation.

Having to parse the type out of the enum just to log that via a conditional is possible but no one will do that for a few reasons.

Instead of feeling bad for you I'll be sending you lots of love and support :heart:

[ra0x3]

@Braqzen

• To be clear, you can very much log(Identity) and access the data via a LogData receipt
• Let me try this out tomorrow and report back