We are excited to announce the release of Cadence v1.0! 🎉

Starting with this release, there will be no more planned breaking changes going forward! 🚀

Reflecting two years of work since the last major milestone in 2022, v0.24 (Secure Cadence), and the culmination of five years of work since the inception of Cadence in 2019, Cadence 1.0 is a milestone marking several significant enhancements. This release introduces full forward compatibility, enhanced composability through Attachments, and significant performance improvements.

We would like to thank all contributors and community members for their great feedback and amazing contributions – this would have not been possible without you! 🙇

To learn more, visit https://flow.com/upgrade/crescendo/cadence-1.

💫 New features

Attachments

Attachments allow developers to extend a struct or resource type (even one that they did not declare) with new functionality and data, without requiring the original author of the type to plan or account for it.

This feature allows developers to easily build on and extend any existing application, significantly improving the composability story of Cadence.

Entitlements and Safe Downcasting

In Cadence 1.0, access control has improved significantly.

Previously, Cadence’s main access-control mechanism, restricted reference types, has been a source of confusion and mistakes for contract developers. Additionally, references could not be downcast, leading to ergonomic issues.

Access control is now handled using a new feature called Entitlements. A reference can now be “entitled” to certain facets of an object.

References can now always be down-casted, the standalone auth modifier is not necessary anymore, and got removed.

Entitled Account Access

Previously, access to accounts was granted wholesale: Users would sign a transaction, authorizing the code of the transaction to perform any kind of operation, for example, write to storage, but also add keys or contracts.

Users had to trust that a transaction would only perform supposed access, e.g. storage access to withdraw tokens, but still had to grant full access, which would allow the transaction to perform other operations.

Dapp developers who require users to sign transactions are now able to request the minimum amount of access to perform the intended operation, i.e. developers are able to follow the principle of least privilege (PoLA).

With the introduction of entitlements, this access is now expressed using entitlements and references.

Access to administrative account operations, such as writing to storage, adding keys, or adding contracts, is now gated by both coarse grained entitlements (e.g. Storage, which grants access to all storage related functions, and Keys, which grants access to all key management functions), as well as fine-grained entitlements (e.g. SaveValue to save a value to storage, or AddKey to add a new key to the account).

Transactions can now request the particular entitlements necessary to perform the operations in the transaction.

View Functions

View functions allow developers to improve the reliability and safety of their programs, and helps them to reason about the effects of their and the programs of others.

Developers can mark their functions as view, which disallows the function from performing state changes. That also makes the intent of functions clear to other programmers, as it allows them to distinguish between functions that change state and ones that do not.

Interface Inheritance

Previously, interfaces could not inherit from other interfaces, which required developers to repeat code. Interface inheritance allows code abstraction and code reuse.

Interfaces can now inherit from other interfaces of the same kind. This makes it easier for developers to structure their conformances and reduces a lot of redundant code.

Capability Controllers

Cadence encourages a capability-based security model. Capabilities are themselves a new concept that most Cadence programmers need to understand.

The existing linking-based capability API has been replaced by a more powerful and easier to use API based on the notion of Capability Controllers. The new API makes the creation of new and the revocation of existing capabilities simpler.

External Mutation Safety

External Mutation Safety prevents a common safety foot-gun, unintentionally granting mutable access to nested data.

The mutability of containers (updating a field of a composite value, key of a map, or index of an array) through references has changed: When a field/element is accessed through a reference, a reference to the accessed inner object is returned, instead of the actual object. These returned references are unauthorized by default, and the author of the object (struct/resource/etc.) can control what operations are permitted on these returned references by using entitlements and entitlement mappings.

Event Definition And Emission In Interfaces

Contract interfaces may now define event types, and these events can be emitted from function conditions and default implementations in those contract interfaces.

Force Destruction of Resources

All resources are now guaranteed to be destroyable.

It was previously possible to panic in the body of a resource or attachment’s destroy method, effectively preventing the destruction or removal of that resource from an account. This could be used as an attack vector by handing people undesirable resources or hydrating resources to make them extremely large or otherwise contain undesirable content.

Contracts may no longer define destroy functions on their resources, and are no longer required to explicitly handle the destruction of resource fields. These will instead be implicitly
destroyed whenever a resource is destroyed.

Additionally, developers may define a ResourceDestroyed event which will be emitted whenever a resource of that type is destroyed.

Inlined and Deduplicated Storage

Cadence uses the Atree library for storing objects. Cadence 1.0 integrates Atree v0.8.0, which inlines and deduplicates stored data, which significantly reduces the amount of data stored and memory need. On Flow Testnet, this reduced memory usage by ~1/2 without sacrificing speed.

For more information, visit the release page https://github.com/onflow/atree/releases/tag/v0.8.0

⚡ Breaking Improvements

Many of the improvements of Cadence 1.0 fundamentally change how Cadence works and how it is used. That also means it was necessary to break existing code to release this version, which guarantees stability (no more planned breaking changes) going forward.

As breaking changes are simply no longer acceptable after Cadence 1.0, we used this last chance to fix and improve Cadence, ensuring it delivers on its promise of being a language that provides security and safety, while also enabling composability and simplicity.

We appreciate that updating existing code can be challenging for developers. However, we believe these improvements are worthwhile, as they make Cadence development significantly more powerful and efficient, enabling developers to write and deploy immutable contracts.

The improvements were intentionally bundled into one release to avoid breaking Cadence programs multiple times.

References to Resource-Kinded Values Get Invalidated When the Referenced Values Are Moved

References are now invalidated if the referenced resource is moved after the reference was taken. The reference is invalidated upon the first move, regardless of the origin and the destination.

Previously, when a reference is taken to a resource, that reference remains valid even if the resource was moved, for example when created and moved into an account, or moved from one account into another.

In other words, references to resources stayed alive forever. This could be a potential safety foot-gun, where one could gain/give/retain unintended access to resources through references.

Conditions No Longer Allow State Changes

In the current version of Cadence, pre-conditions and post-conditions may perform state changes, e.g. by calling a function that performs a mutation. This may result in unexpected behavior, which might lead to bugs.

To make conditions predictable, they are no longer allowed to perform state changes.

Pre-conditions and post-conditions are now considered view contexts, meaning that any operations that would be prevented inside of a view function are also not permitted in a pre-condition or post-condition.

This is to prevent underhanded code wherein a user modifies global or contract state inside of a condition, where they are meant to simply be asserting properties of that state.

Semantics for Variables in For-Loop Statements Got Improved

The behavior of for-in loops improved, so that a new iteration variable is introduced for each iteration.

Previously, the iteration variable of for-in loops was re-assigned on each iteration.

Even though this is a common behavior in many programming languages, it is surprising behavior and a source of bugs.

The behavior was improved to the often assumed/expected behavior of a new iteration variable being introduced for each iteration, which reduces the likelihood for a bug.

Restricted Types Got Replaced with Intersection Types

With the improvements to access control enabled by entitlements and safe down-casting, the restricted type feature is redundant.

Restricted types have been removed. All types, including references, can now be down-casted, restricted types are no longer used for access control. At the same time intersection types got introduced.

Definite Return Analysis Got Improved

The definite return analysis got significantly improved.

Definite return analysis determines if a function always exits, in all possible execution paths, e.g. through a return statement, or by calling a function that never returns, like panic.

This analysis was incomplete and required developers to add workarounds to their code.

Syntax for Function Types Improved

Previously, function types were expressed using a different syntax from function declarations or expressions. The previous syntax was unintuitive for developers, making it hard to write and read code that used function types.

Function types are now expressed using the fun keyword, just like expressions and declarations. This improves readability and makes function types more obvious.

`pub` and `priv` Access Modifiers Got Removed

The pub, priv and pub(set) access modifiers got removed from the language, in favor of their more explicit access(all) and access(self) equivalents (for pub and priv, respectively).

This makes access modifiers more uniform and better match the new entitlements syntax.

Naming Rules Got Tightened

Previously, Cadence allowed language keywords (e.g. continue, for, etc.) to be used as names. This had the potential to confuse developers or readers of programs, and could potentially lead to bugs.

Most language keywords are no longer allowed to be used as names. Some keywords are still allowed to be used as names, as they have limited significance within the language.

Nested Type Requirements Got Removed

Nested Type Requirements were a fairly advanced concept of the language. The feature was uncommon in other programming languages and hard to understand.

Just like an interface could require a conforming type to provide a certain field or function, it could also have required the conforming type to provide a nested type.

Deprecated Key Management API Got Removed

Cadence provided two key management APIs:

The original, low-level API, which worked with RLP-encoded keys
The improved, high-level API, which works with convenient data types like PublicKey, HashAlgorithm, and SignatureAlgorithm

The original account key management API, got removed. The improved API was introduced, as the original API was difficult to use and error-prone. The original API was deprecated in early 2022.

Result of `toBigEndianBytes()` for `U?Int(128|256)` Fixed

Previously, the implementation of .toBigEndianBytes() was incorrect for the large integer types Int128, Int256, UInt128, and UInt256. This had the potential to confuse developers or readers of programs, and could potentially lead to bugs.

The result for toBigEndianBytes() on ****Int128 and UInt128 is now always an array of 16 bytes, and for Int256 and UInt256 32 bytes.

🐞 Bugfixes

Resource Tracking for Optional Bindings Improved

Resource tracking for optional bindings (”if-let statements”) was fixed.

Previously, resource tracking for optional bindings was implemented incorrectly, leading to errors for valid code. This required developers to add workarounds to their code.

Missing or Incorrect Argument Labels Get Reported

Function calls with missing argument labels and function calls with incorrect argument labels are now reported properly.

Previously, missing or incorrect argument labels of function calls were not reported.

This had the potential to confuse developers or readers of programs, and could potentially lead to bugs.

Incorrect Operators in Reference Expressions Get Reported

Previously, incorrect operators in reference expressions were not reported.