Since the last spork in August, which deployed Cadence v0.25.0, the Cadence team has been busy and released three major versions of Cadence. These changes have been deployed on Testnet as part of the Testnet spork on October 19th by deploying Cadence v0.28.0 and will be deployed to Mainnet on November 2nd.
We wanted to highlight several of the new features and improvements of Cadence v0.26.0 to v0.28.0.
Paths can now be compared and the
() literal has been introduced to construct the
Interface Default Functions
Cadence now supports default implementations in interfaces: If a type that implements an interface does not provide an implementation for a function required by the interface, then the interface’s default function, if any, is used in the implementation.
This feature reduces the amount of code, developers have to write to adopt an interface and is also useful for updating interfaces in a backwards-compatible way.
Cadence now supports iterating over account storage with a suite of new fields and functions on account objects:
let publicPaths: [PublicPath]
let privatePaths: [PrivatePath]
let storagePaths: [StoragePath]
fun forEachPublic(_ function: ((PublicPath, Type): Bool))
fun forEachPrivate(_ function: ((PrivatePath, Type): Bool))
fun forEachStored(_ function: ((StoragePath, Type): Bool))
This new API is available on the
AuthAcccount object, and the
PublicPath-specific features are also available on
Paths fields are arrays containing all the paths in use in each of the
/storage domains, while the three new methods iterate over these storage domains, applying the provided callback function to each path in the domain. The first parameter of this callback function is the actual
Path value in question, while the
Type parameter is the runtime type of the value stored at that
Path. So if a user had previously stored a value of type
/storage/myNFTpath, these arguments to this function when considering that path would be
These functions by default do not load the actual value stored at each path, as this is a potentially expensive operation, and also has the potential to mutate storage. If users wish to inspect the actual stored values during iteration (as opposed to just the
Types), we recommend doing so with
borrow (in the case of
storage paths) or
getCapability (in the case of
private paths) in the body of the callback function.
Bool return of the callback function indicates whether should continue after the callback finishes executing for a path;
true causing iteration to continue and
false causing it to terminate. So, for example, when using these functions to search storage for a value satisfying a specific predicate, one might return
false after such a value is found in order to prevent needlessly checking all the other stored values.
More details about this new API can be found here, including some important caveats about the order of iteration and how mutation is handled.
With this new API, scripts like this one to get all the NFTs in an account will be significantly easier to write and will not need to rely on libraries like the
NFTCatalog, which require manual approval of each new NFT type. In general, user agents like wallets will now be able to introspect accounts and display their content without needing to explicitly handle and support specific data types and paths.
Cadence now provides the function
String.fromUTF8 which can be used to convert a byte array of UTF-8 data (
[UInt8]) into a string.
In addition, the number types, like
UInt64, have gained a
fromString function, which can be used to convert a
String to the number.
It is now possible to iterate over dictionaries’ keys using the
The new Cadence testing framework provides a convenient way to write tests for Cadence programs in Cadence. To learn more about writing tests in Cadence, have a look at the documentation here.
The testing framework will be available through the flow-CLI. See here on how to run tests using the CLI.
The type checking for resources has been fixed and significantly improved, especially for cases where control flow statements (e.g.
continue, etc.) are involved.
In addition, some of the error messages have been improved. For example, for type mismatch errors, the error message now includes both the actual and the expected type.
All components of Cadence, i.e. the parser, type checker, and interpreter, have been optimized in multiple ways. As a result, Cadence has gotten significantly faster and its memory consumption has been reduced.
The REPL has been improved and is now able to gracefully handle static errors, such as parsing or type-checking errors, as well as execution errors.
|Release v0.25.1 · onflow/cadence · GitHub
|Sept 20, 2022
|Release v0.25.2 · onflow/cadence · GitHub
|Sept 20, 2022
|Release v0.26.0 · onflow/cadence · GitHub
|Aug 23, 2022
|Release v0.26.1 · onflow/cadence · GitHub
|Sept 16, 2022
|Release v0.26.2 · onflow/cadence · GitHub
|Sept 23, 2022
|Release v0.27.0 · onflow/cadence · GitHub
|Sept 23, 2022
|Release v0.27.1 · onflow/cadence · GitHub
|Oct 3, 2022
|Release v0.28.0 · onflow/cadence · GitHub
|Oct 6, 2022