sway

sway copied to clipboard

We currently have const values which must be hardcoded. For values which can't be hardcoded, or are subject to change, we have storage.

Configuration-time constants (in Solidity these are immutable variables) give us a third option which fits nicely in between the existing 2.

These are variables which are like const values in that they can't be changed once set, but their value is set at configuration time. In Solidity this is done via the constructor. We don't have a concept of constructor in Sway, so this might be done in an init function (just a normal abi function which must be made to be callable only once) or perhaps via some other mechanism.

so this might be done in an init function (just a normal abi function which must be made to be callable only once) or perhaps via some other mechanism.

This is how you'd do it today. That doesn't really work if you want configuration-time constants to be baked into the bytecode, which you do.

A simple proposal is a section in the Forc manifest, e.g. [immutables], where the user can list configuration-time constants that are then inserted into the code as literals. Type and value could be specified as

[immutables]
MY_CONSTANT = "u64:420"

The compiler would then replace any identifiers with the name MY_CONSTANT with the literal 420 with type u64.

Could you clarify what "configuration time" means and how it differs from compile-time?

IIRC, this is about being able to more easily change between certain constants like addresses or IDs so you can easily test with different values to what you end up deploying, and similar scenarios right?

@adlerjohn I remember us discussing this on another issue but can't think of where :thinking:

Configuration-time here means known at compile time but not the same across instantiations of the contract. Examples would be parameters of a contract that don't change after a contract is deployed, e.g. the two asset IDs of a pool contract, or some timeout parameter for an auction.