Support for Enum Types as Direct Transaction Parameters

[justinrandom]

Issue to be solved

Issue to be Solved

Currently, enums cannot be used directly as transaction parameters in the Cadence language. This limitation requires developers to use integer values to represent enum cases, which reduces code readability and increases the risk of errors due to incorrect mappings between integers and their corresponding enum cases. This issue affects the security and usability of smart contracts, as users must be aware of the specific integer values representing each enum case, leading to potential mistakes and confusion.

In-scope:

• Allowing enum types to be directly used as transaction parameters.

• Improving the security and usability of smart contracts by enabling intuitive use of enums.

Out-of-scope:

• Changing existing enum functionalities or how enums are defined within contracts.

• Modifying how integer values are currently used in other parts of the language.

Suggested Solution

Details of the Technical Implementation:

• Update the Cadence language to support enum types as valid transaction parameters.

• Allow developers to define enums within contracts and use them directly in transaction arguments.

• Ensure that the Cadence runtime can correctly interpret and validate enum values during transaction execution.

Tradeoffs Made in Design Decisions:

• Pro: Enhanced readability and reduced risk of errors by using enums directly.

• Pro: Improved developer experience and code maintainability.

• Con: Requires updates to the Cadence language and runtime, which may involve significant development resources and testing.

Caveats and Considerations for the Future:

Ensure backward compatibility with existing contracts that use integers to represent enums.
Provide thorough documentation and examples to help developers transition to using enums as transaction parameters.
Consider potential performance implications of supporting enums in transaction parameters and optimize as necessary.

Example of Preferred Solution:

Currently, a transaction script might require the user to input an integer value to represent an enum case, such as:

import ExampleContract from 0x01

transaction(enumRawValue: UInt8) {
    let adminRef: &ExampleContract.Admin

    prepare(signer: AuthAccount) {
        self.adminRef = signer.borrow<&ExampleContract.Admin>(from: /storage/Admin)
            ?? panic("Could not borrow a reference to the Admin resource")
    }

    execute {
        let enumValue: ExampleContract.EnumType = ExampleContract.EnumType(rawValue: enumRawValue) ?? panic("Invalid enum value")
        self.adminRef.updateEnumValue(value: enumValue)
    }
}

In this script, the user must provide an integer representing the enum value. With the proposed enhancement, the script could be simplified to:

import ExampleContract from 0x01

transaction(enumValue: ExampleContract.EnumType) {
    let adminRef: &ExampleContract.Admin

    prepare(signer: AuthAccount) {
        self.adminRef = signer.borrow<&ExampleContract.Admin>(from: /storage/Admin)
            ?? panic("Could not borrow a reference to the Admin resource")
    }

    execute {
        self.adminRef.updateEnumValue(value: enumValue)
    }
}

[SupunS]

Enums are already supported as transaction parameters (and has been there for while). Hence we'll be closing the issue.
Thanks @RZhang05 for adding tests in #3581.

@justinrandom Was there any particular issue / any specific error you ran into? If so, please feel free to re-open with the error details.