Skip to main content
Version: Next

Interfaces

An interface is an abstract type that specifies the behavior of types that implement the interface. Interfaces declare the required functions and fields, the access control for those declarations, and preconditions and postconditions that implementing types need to provide.

There are three kinds of interfaces:

  • Structure interfaces: implemented by structures
  • Resource interfaces: implemented by resources
  • Contract interfaces: implemented by contracts

Structure, resource, and contract types may implement multiple interfaces.

There is no support for event and enum interfaces.

Nominal typing applies to composite types that implement interfaces. This means that a type only implements an interface if it has explicitly declared the conformance, the composite type does not implicitly conform to an interface, even if it satisfies all requirements of the interface.

Interfaces consist of the function and field requirements that a type implementing the interface must provide implementations for. Interface requirements, and therefore also their implementations, must always be at least public.

Variable field requirements may be annotated to require them to be publicly settable.

Function requirements consist of the name of the function, parameter types, an optional return type, and optional preconditions and postconditions.

Field requirements consist of the name and the type of the field. Field requirements may optionally declare a getter requirement and a setter requirement, each with preconditions and postconditions.

Calling functions with preconditions and postconditions on interfaces instead of concrete implementations can improve the security of a program, as it ensures that even if implementations change, some aspects of them will always hold.

Interface Declaration

Interfaces are declared using the struct, resource, or contract keyword, followed by the interface keyword, the name of the interface, and the requirements, which must be enclosed in opening and closing braces.

Field requirements can be annotated to require the implementation to be a variable field, by using the var keyword; require the implementation to be a constant field, by using the let keyword; or the field requirement may specify nothing, in which case the implementation may either be a variable or a constant field.

Field requirements and function requirements must specify the required level of access. The access must be at least be public, so the access(all) keyword must be provided.

Interfaces can be used in types. This is explained in detail in the section Interfaces in Types. For now, the syntax {I} can be read as the type of any value that implements the interface I.


_77
// Declare a resource interface for a fungible token.
_77
// Only resources can implement this resource interface.
_77
//
_77
access(all) resource interface FungibleToken {
_77
_77
// Require the implementing type to provide a field for the balance
_77
// that is readable in all scopes (`access(all)`).
_77
//
_77
// Neither the `var` keyword, nor the `let` keyword is used,
_77
// so the field may be implemented as either a variable
_77
// or as a constant field.
_77
//
_77
access(all) balance: Int
_77
_77
// Require the implementing type to provide an initializer that
_77
// given the initial balance, must initialize the balance field.
_77
//
_77
init(balance: Int) {
_77
pre {
_77
balance >= 0:
_77
"Balances are always non-negative"
_77
}
_77
post {
_77
self.balance == balance:
_77
"the balance must be initialized to the initial balance"
_77
}
_77
_77
// NOTE: The declaration contains no implementation code.
_77
}
_77
_77
// Require the implementing type to provide a function that is
_77
// callable in all scopes, which withdraws an amount from
_77
// this fungible token and returns the withdrawn amount as
_77
// a new fungible token.
_77
//
_77
// The given amount must be positive and the function implementation
_77
// must add the amount to the balance.
_77
//
_77
// The function must return a new fungible token.
_77
// The type `{FungibleToken}` is the type of any resource
_77
// that implements the resource interface `FungibleToken`.
_77
//
_77
access(all) fun withdraw(amount: Int): @{FungibleToken} {
_77
pre {
_77
amount > 0:
_77
"the amount must be positive"
_77
amount <= self.balance:
_77
"insufficient funds: the amount must be smaller or equal to the balance"
_77
}
_77
post {
_77
self.balance == before(self.balance) - amount:
_77
"the amount must be deducted from the balance"
_77
}
_77
_77
// NOTE: The declaration contains no implementation code.
_77
}
_77
_77
// Require the implementing type to provide a function that is
_77
// callable in all scopes, which deposits a fungible token
_77
// into this fungible token.
_77
//
_77
// No precondition is required to check the given token's balance
_77
// is positive, as this condition is already ensured by
_77
// the field requirement.
_77
//
_77
// The parameter type `{FungibleToken}` is the type of any resource
_77
// that implements the resource interface `FungibleToken`.
_77
//
_77
access(all) fun deposit(_ token: @{FungibleToken}) {
_77
post {
_77
self.balance == before(self.balance) + token.balance:
_77
"the amount must be added to the balance"
_77
}
_77
_77
// NOTE: The declaration contains no implementation code.
_77
}
_77
}

Note that the required initializer and functions do not have any executable code.

Struct and resource Interfaces can only be declared directly inside contracts, i.e. not inside of functions. Contract interfaces can only be declared globally and not inside contracts.

Interface Implementation

Declaring that a type implements (conforms) to an interface is done in the type declaration of the composite type (e.g., structure, resource): The kind and the name of the composite type is followed by a colon (:) and the name of one or more interfaces that the composite type implements.

This will tell the checker to enforce any requirements from the specified interfaces onto the declared type.

A type implements (conforms to) an interface if it declares the implementation in its signature, provides field declarations for all fields required by the interface, and provides implementations for all functions required by the interface.

The field declarations in the implementing type must match the field requirements in the interface in terms of name, type, and declaration kind (e.g. constant, variable) if given. For example, an interface may require a field with a certain name and type, but leaves it to the implementation what kind the field is.

The function implementations must match the function requirements in the interface in terms of name, parameter argument labels, parameter types, and the return type.


_104
// Declare a resource named `ExampleToken` that has to implement
_104
// the `FungibleToken` interface.
_104
//
_104
// It has a variable field named `balance`, that can be written
_104
// by functions of the type, but outer scopes can only read it.
_104
//
_104
access(all) resource ExampleToken: FungibleToken {
_104
_104
// Implement the required field `balance` for the `FungibleToken` interface.
_104
// The interface does not specify if the field must be variable, constant,
_104
// so in order for this type (`ExampleToken`) to be able to write to the field,
_104
// but limit outer scopes to only read from the field, it is declared variable,
_104
// and only has public access (non-settable).
_104
//
_104
access(all) var balance: Int
_104
_104
// Implement the required initializer for the `FungibleToken` interface:
_104
// accept an initial balance and initialize the `balance` field.
_104
//
_104
// This implementation satisfies the required postcondition.
_104
//
_104
// NOTE: the postcondition declared in the interface
_104
// does not have to be repeated here in the implementation.
_104
//
_104
init(balance: Int) {
_104
self.balance = balance
_104
}
_104
_104
// Implement the required function named `withdraw` of the interface
_104
// `FungibleToken`, that withdraws an amount from the token's balance.
_104
//
_104
// The function must be public.
_104
//
_104
// This implementation satisfies the required postcondition.
_104
//
_104
// NOTE: neither the precondition nor the postcondition declared
_104
// in the interface have to be repeated here in the implementation.
_104
//
_104
access(all) fun withdraw(amount: Int): @ExampleToken {
_104
self.balance = self.balance - amount
_104
return create ExampleToken(balance: amount)
_104
}
_104
_104
// Implement the required function named `deposit` of the interface
_104
// `FungibleToken`, that deposits the amount from the given token
_104
// to this token.
_104
//
_104
// The function must be public.
_104
//
_104
// NOTE: the type of the parameter is `{FungibleToken}`,
_104
// i.e., any resource that implements the resource interface `FungibleToken`,
_104
// so any other token – however, we want to ensure that only tokens
_104
// of the same type can be deposited.
_104
//
_104
// This implementation satisfies the required postconditions.
_104
//
_104
// NOTE: neither the precondition nor the postcondition declared
_104
// in the interface have to be repeated here in the implementation.
_104
//
_104
access(all) fun deposit(_ token: @{FungibleToken}) {
_104
if let exampleToken <- token as? ExampleToken {
_104
self.balance = self.balance + exampleToken.balance
_104
destroy exampleToken
_104
} else {
_104
panic("cannot deposit token which is not an example token")
_104
}
_104
}
_104
}
_104
_104
// Declare a constant which has type `ExampleToken`,
_104
// and is initialized with such an example token.
_104
//
_104
let token <- create ExampleToken(balance: 100)
_104
_104
// Withdraw 10 units from the token.
_104
//
_104
// The amount satisfies the precondition of the `withdraw` function
_104
// in the `FungibleToken` interface.
_104
//
_104
// Invoking a function of a resource does not destroy the resource,
_104
// so the resource `token` is still valid after the call of `withdraw`.
_104
//
_104
let withdrawn <- token.withdraw(amount: 10)
_104
_104
// The postcondition of the `withdraw` function in the `FungibleToken`
_104
// interface ensured the balance field of the token was updated properly.
_104
//
_104
// `token.balance` is `90`
_104
// `withdrawn.balance` is `10`
_104
_104
// Deposit the withdrawn token into another one.
_104
let receiver: @ExampleToken <- // ...
_104
receiver.deposit(<-withdrawn)
_104
_104
// Run-time error: The precondition of function `withdraw` in interface
_104
// `FungibleToken` fails, the program aborts: the parameter `amount`
_104
// is larger than the field `balance` (100 > 90).
_104
//
_104
token.withdraw(amount: 100)
_104
_104
// Withdrawing tokens so that the balance is zero does not destroy the resource.
_104
// The resource has to be destroyed explicitly.
_104
//
_104
token.withdraw(amount: 90)

The access level for variable fields in an implementation may be less restrictive than the interface requires. For example, an interface may require a field to be at least contract-accessible (i.e. the access(contract) modifier is used), and an implementation may provide a variable field which is public, (the access(all) modifier is used).


_18
access(all) struct interface AnInterface {
_18
// Require the implementing type to provide a contract-readable
_18
// field named `a` that has type `Int`. It may be a variable
_18
// or a constant field.
_18
//
_18
access(contract) a: Int
_18
}
_18
_18
access(all) struct AnImplementation: AnInterface {
_18
// Declare a public variable field named `a` that has type `Int`.
_18
// This implementation satisfies the requirement for interface `AnInterface`:
_18
//
_18
access(all) var a: Int
_18
_18
init(a: Int) {
_18
self.a = a
_18
}
_18
}

Interfaces in Types

Interfaces can be used in types: The type {I} is the type of all objects that implement the interface I.

This is called a intersection type: Only the functionality (members and functions) of the interface can be used when accessing a value of such a type.


_70
// Declare an interface named `Shape`.
_70
//
_70
// Require implementing types to provide a field which returns the area,
_70
// and a function which scales the shape by a given factor.
_70
//
_70
access(all) struct interface Shape {
_70
access(all) fun getArea(): Int
_70
access(all) fun scale(factor: Int)
_70
}
_70
_70
// Declare a structure named `Square` the implements the `Shape` interface.
_70
//
_70
access(all) struct Square: Shape {
_70
// In addition to the required fields from the interface,
_70
// the type can also declare additional fields.
_70
//
_70
access(all) var length: Int
_70
_70
// Provided the field `area` which is required to conform
_70
// to the interface `Shape`.
_70
//
_70
// Since `area` was not declared as a constant, variable,
_70
// field in the interface, it can be declared.
_70
//
_70
access(all) fun getArea(): Int {
_70
return self.length * self.length
_70
}
_70
_70
access(all) init(length: Int) {
_70
self.length = length
_70
}
_70
_70
// Provided the implementation of the function `scale`
_70
// which is required to conform to the interface `Shape`.
_70
//
_70
access(all) fun scale(factor: Int) {
_70
self.length = self.length * factor
_70
}
_70
}
_70
_70
// Declare a structure named `Rectangle` that also implements the `Shape` interface.
_70
//
_70
access(all) struct Rectangle: Shape {
_70
access(all) var width: Int
_70
access(all) var height: Int
_70
_70
// Provided the field `area which is required to conform
_70
// to the interface `Shape`.
_70
//
_70
access(all) fun getArea(): Int {
_70
return self.width * self.height
_70
}
_70
_70
access(all) init(width: Int, height: Int) {
_70
self.width = width
_70
self.height = height
_70
}
_70
_70
// Provided the implementation of the function `scale`
_70
// which is required to conform to the interface `Shape`.
_70
//
_70
access(all) fun scale(factor: Int) {
_70
self.width = self.width * factor
_70
self.height = self.height * factor
_70
}
_70
}
_70
_70
// Declare a constant that has type `Shape`, which has a value that has type `Rectangle`.
_70
//
_70
var shape: {Shape} = Rectangle(width: 10, height: 20)

Values implementing an interface are assignable to variables that have the interface as their type.


_10
// Assign a value of type `Square` to the variable `shape` that has type `Shape`.
_10
//
_10
shape = Square(length: 30)
_10
_10
// Invalid: cannot initialize a constant that has type `Rectangle`.
_10
// with a value that has type `Square`.
_10
//
_10
let rectangle: Rectangle = Square(length: 10)

Fields declared in an interface can be accessed and functions declared in an interface can be called on values of a type that implements the interface.


_14
// Declare a constant which has the type `Shape`.
_14
// and is initialized with a value that has type `Rectangle`.
_14
//
_14
let shape: {Shape} = Rectangle(width: 2, height: 3)
_14
_14
// Access the field `area` declared in the interface `Shape`.
_14
//
_14
shape.area // is `6`
_14
_14
// Call the function `scale` declared in the interface `Shape`.
_14
//
_14
shape.scale(factor: 3)
_14
_14
shape.area // is `54`

Interface Nesting

info

🚧 Status: Currently only contracts and contract interfaces support nested interfaces.

Interfaces can be arbitrarily nested. Declaring an interface inside another does not require implementing types of the outer interface to provide an implementation of the inner interfaces.


_23
// Declare a resource interface `OuterInterface`, which declares
_23
// a nested structure interface named `InnerInterface`.
_23
//
_23
// Resources implementing `OuterInterface` do not need to provide
_23
// an implementation of `InnerInterface`.
_23
//
_23
// Structures may just implement `InnerInterface`.
_23
//
_23
resource interface OuterInterface {
_23
_23
struct interface InnerInterface {}
_23
}
_23
_23
// Declare a resource named `SomeOuter` that implements the interface `OuterInterface`.
_23
//
_23
// The resource is not required to implement `OuterInterface.InnerInterface`.
_23
//
_23
resource SomeOuter: OuterInterface {}
_23
_23
// Declare a structure named `SomeInner` that implements `InnerInterface`,
_23
// which is nested in interface `OuterInterface`.
_23
//
_23
struct SomeInner: OuterInterface.InnerInterface {}

Interface Default Functions

Interfaces can provide default functions: If the concrete type implementing the interface does not provide an implementation for the function required by the interface, then the interface's default function is used in the implementation.


_27
// Declare a struct interface `Container`,
_27
// which declares a default function `getCount`.
_27
//
_27
struct interface Container {
_27
_27
let items: [AnyStruct]
_27
_27
fun getCount(): Int {
_27
return self.items.length
_27
}
_27
}
_27
_27
// Declare a concrete struct named `Numbers` that implements the interface `Container`.
_27
//
_27
// The struct does not implement the function `getCount` of the interface `Container`,
_27
// so the default function for `getCount` is used.
_27
//
_27
struct Numbers: Container {
_27
let items: [AnyStruct]
_27
_27
init() {
_27
self.items = []
_27
}
_27
}
_27
_27
let numbers = Numbers()
_27
numbers.getCount() // is 0

Interfaces cannot provide default initializers or default destructors.

Only one conformance may provide a default function.

Nested Type Requirements

info

🚧 Status: Currently only contracts and contract interfaces support nested type requirements.

Interfaces can require implementing types to provide concrete nested types. For example, a resource interface may require an implementing type to provide a resource type.


_23
// Declare a resource interface named `FungibleToken`.
_23
//
_23
// Require implementing types to provide a resource type named `Vault`
_23
// which must have a field named `balance`.
_23
//
_23
resource interface FungibleToken {
_23
access(all) resource Vault {
_23
access(all) balance: Int
_23
}
_23
}
_23
_23
// Declare a resource named `ExampleToken` that implements the `FungibleToken` interface.
_23
//
_23
// The nested type `Vault` must be provided to conform to the interface.
_23
//
_23
resource ExampleToken: FungibleToken {
_23
access(all) resource Vault {
_23
access(all) var balance: Int
_23
init(balance: Int) {
_23
self.balance = balance
_23
}
_23
}
_23
}

Interface inheritance

An interface can inherit from (conform to) other interfaces of the same kind. For example, a resource interface can inherit from another resource interface, but cannot inherit from a struct interface. When an interface inherits from another, all the fields, functions, and types of the parent interface are implicitly available to the inheriting interface.


_10
access(all) resource interface Receiver {
_10
access(all) fun deposit(_ something: @AnyResource)
_10
}
_10
_10
// `Vault` interface inherits from `Receiver` interface.
_10
access(all) resource interface Vault: Receiver {
_10
access(all) fun withdraw(_ amount: Int): @Vault
_10
}

In the example above, Vault inherits Receiver. Anyone implementing the Vault interface would also have to implement the Receiver interface.


_10
access(all) resource MyVault: Vault {
_10
// Must implement all the methods coming from both `Vault` and `Receiver` interfaces.
_10
access(all) fun deposit(_ something: @AnyResource) {}
_10
_10
access(all) fun withdraw(_ amount: Int): @Vault {}
_10
}

Duplicate interface members

When an interface implements another interface, it is possible for the two interfaces to have members (functions, fields, and type requirements) with the same name. The following sections explain how these ambiguities are resolved for different scenarios.

Fields

If two fields with identical names have identical types, then it will be valid.


_10
access(all) resource interface Receiver {
_10
access(all) var id: UInt64
_10
}
_10
_10
access(all) resource interface Vault: Receiver {
_10
// `id` field has the same type as the `Receiver.id`. Hence this is valid.
_10
access(all) var id: UInt64
_10
}

Otherwise, interface conformance is not valid.


_10
access(all) resource interface Receiver {
_10
access(all) var id: Int
_10
}
_10
_10
access(all) resource interface Vault: Receiver {
_10
// `id` field has a different type than the `Receiver.id`. Hence this is invalid.
_10
access(all) var id: UInt64
_10
}

Functions

If two functions with identical names also have identical signatures, that is valid.


_10
access(all) resource interface Receiver {
_10
access(all) fun deposit(_ something: @AnyResource)
_10
}
_10
_10
access(all) resource interface Vault: Receiver {
_10
// `deposit` function has the same signature as the `Receiver.deposit`.
_10
// Also none of them have any default implementations.
_10
// Hence this is valid.
_10
access(all) fun deposit(_ something: @AnyResource)
_10
}

If the signatures of the two functions are different, then the interface conformance is not valid.


_10
access(all) resource interface Receiver {
_10
access(all) fun deposit(_ something: @AnyResource)
_10
}
_10
_10
access(all) resource interface Vault: Receiver {
_10
// Error: `deposit` function has a different signature compared to the `Receiver.deposit`.
_10
// So these two cannot co-exist.
_10
access(all) fun deposit()
_10
}

Functions with conditions

If the two functions with identical names and signatures have pre/post conditions, then it will still be valid. However, the pre/post conditions are linearized (refer to the linearizing conditions section) to determine the order of the execution of the conditions. Given the pre/post conditions are view only, the order of execution would not have an impact on the conditions.


_14
access(all) resource interface Receiver {
_14
access(all) fun deposit(_ something: @AnyResource) {
_14
pre{ self.balance > 100 }
_14
}
_14
}
_14
_14
access(all) resource interface Vault: Receiver {
_14
// `deposit` function has the same signature as the `Receiver.deposit`.
_14
// Having pre/post condition is valid.
_14
// Both conditions would be executed, in a pre-determined order.
_14
access(all) fun deposit(_ something: @AnyResource) {
_14
pre{ self.balance > 50 }
_14
}
_14
}

Default functions

An interface can provide a default implementation to an inherited function.


_10
access(all) resource interface Receiver {
_10
access(all) fun log(_ message: String)
_10
}
_10
_10
access(all) resource interface Vault: Receiver {
_10
// Valid: Provides the implementation for `Receiver.log` method.
_10
access(all) fun log(_ message: String) {
_10
log(message.append("from Vault"))
_10
}
_10
}

However, an interface cannot override an inherited default implementation of a function.


_12
access(all) resource interface Receiver {
_12
access(all) fun log(_ message: String) {
_12
log(message.append("from Receiver"))
_12
}
_12
}
_12
_12
access(all) resource interface Vault: Receiver {
_12
// Invalid: Cannot override the `Receiver.log` method.
_12
access(all) fun log(_ message: String) {
_12
log(message.append("from Vault"))
_12
}
_12
}

It is also invalid to have two or more inherited default implementations for an interface.


_14
access(all) resource interface Receiver {
_14
access(all) fun log(_ message: String) {
_14
log(message.append("from Receiver"))
_14
}
_14
}
_14
_14
access(all) resource interface Provider {
_14
access(all) fun log(_ message: String) {
_14
log(message.append("from Provider"))
_14
}
_14
}
_14
_14
// Invalid: Two default functions from two interfaces.
_14
access(all) resource interface Vault: Receiver, Provider {}

Having said that, there can be situations where the same default function can be available via different inheritance paths.


_13
access(all) resource interface Logger {
_13
access(all) fun log(_ message: String) {
_13
log(message.append("from Logger"))
_13
}
_13
}
_13
_13
access(all) resource interface Receiver: Logger {}
_13
_13
access(all) resource interface Provider: Logger {}
_13
_13
// Valid: `Logger.log()` default function is visible to the `Vault` interface
_13
// via both `Receiver` and `Provider`.
_13
access(all) resource interface Vault: Receiver, Provider {}

In the above example, Logger.log() default function is visible to the Vault interface via both Receiver and Provider. Even though it is available from two different interfaces, they are both referring to the same default implementation. Therefore, the above code is valid.

Conditions with Default functions

A more complex situation is where a default function is available via one inheritance path and a pre/post condition is available via another inheritance path.


_14
access(all) resource interface Receiver {
_14
access(all) fun log(_ message: String) {
_14
log(message.append("from Receiver"))
_14
}
_14
}
_14
_14
access(all) resource interface Provider {
_14
access(all) fun log(_ message: String) {
_14
pre{ message != "" }
_14
}
_14
}
_14
_14
// Valid: Both the default function and the condition would be available.
_14
access(all) resource interface Vault: Receiver, Provider {}

In such situations, all rules applicable for default functions inheritance as well as condition inheritance would be applied. Thus, the default function from coming from the Receiver interface, and the condition comes from the Provider interface would be made available for the inherited interface.

Types and event definitions

Type and event definitions would also behave similarly to the default functions. Inherited interfaces can override type definitions and event definitions.


_13
access(all) contract interface Token {
_13
access(all) struct Foo {}
_13
}
_13
_13
access(all) contract interface NonFungibleToken: Token {
_13
access(all) struct Foo {}
_13
}
_13
_13
access(all) contract MyToken: NonFungibleToken {
_13
access(all) fun test() {
_13
let foo: Foo // This will refer to the `NonFungibleToken.Foo`
_13
}
_13
}

If a user needed to access the Foo struct coming from the super interface Token, then they can access it using the fully qualified name. e.g: let foo: Token.Foo.

However, it is not allowed to have two or more inherited type/events definitions with identical names for an interface.


_11
access(all) contract interface Token {
_11
access(all) struct Foo {}
_11
}
_11
_11
access(all) contract interface Collectible {
_11
access(all) struct Foo {}
_11
}
_11
_11
// Invalid: Two type definitions with the same name from two interfaces.
_11
access(all) contract NonFungibleToken: Token, Collectible {
_11
}

Similar to default functions, there can be situations where the same type/event definition can be available via different inheritance paths.


_10
access(all) contract interface Logger {
_10
access(all) struct Foo {}
_10
}
_10
_10
access(all) contract interface Token: Logger {}
_10
_10
access(all) contract interface Collectible: Logger {}
_10
_10
// Valid: `Logger.Foo` struct is visible to the `NonFungibleToken` interface via both `Token` and `Collectible`.
_10
access(all) contract interface NonFungibleToken: Token, Collectible {}

In the above example, Logger.Foo type definition is visible to the NonFungibleToken interface via both Token and Collectible. Even though it is available from two different interfaces, they are both referring to the same type definition. Therefore, the above code is valid.

However, if at least one of the interfaces in the middle of the chain also overrides the type definition Foo, then the code becomes invalid, as there are multiple implementations present now, which leads to ambiguity.


_15
access(all) contract interface Logger {
_15
access(all) struct Foo {}
_15
}
_15
_15
access(all) contract interface Token: Logger {
_15
access(all) struct Foo {}
_15
}
_15
_15
access(all) contract interface Collectible: Logger {}
_15
_15
// Invalid: The default implementation of the `Foo` struct by the `Logger`
_15
// interface is visible to the `NonFungibleToken` via the `Collectible` interface.
_15
// Another implementation of `Foo` struct is visible to the `NonFungibleToken` via the `Token` interface.
_15
// This creates ambiguity.
_15
access(all) resource interface NonFungibleToken: Token, Provider {}

Linearizing Conditions

As mentioned in the functions with conditions section, it would be required to linearize the function conditions, to determine the order in which pre- and post-conditions are executed. This is done by linearizing the interfaces, and hence conditions, in a depth-first pre-ordered manner, without duplicates.

For example, consider an interface inheritance hierarchy as below:


_10
A
_10
/ \
_10
B C
_10
/ \ /
_10
D E
_10
where an edge from A (top) to B (bottom) means A inherits B.

This would convert to a Cadence implementation similar to:


_29
struct interface A: B, C {
_29
access(all) fun test() {
_29
pre { print("A") }
_29
}
_29
}
_29
_29
struct interface B: D, E {
_29
access(all) fun test() {
_29
pre { print("B") }
_29
}
_29
}
_29
_29
struct interface C: E {
_29
access(all) fun test() {
_29
pre { print("C") }
_29
}
_29
}
_29
_29
struct interface D {
_29
access(all) fun test() {
_29
pre { print("D") }
_29
}
_29
}
_29
_29
struct interface E {
_29
access(all) fun test() {
_29
pre { print("E") }
_29
}
_29
}

Any concrete type implementing interface A would be equivalent to implementing all interfaces from A to E, linearized.


_10
struct Foo: A {
_10
access(all) fun test() {
_10
pre { print("Foo") }
_10
}
_10
}

The linearized interface order would be: [A, B, D, E, C].

i.e: same as having:


_10
struct Foo: A, B, D, C, E {
_10
access(all) fun test() {
_10
pre { print("Foo") }
_10
}
_10
}

Thus, invoking test method of Foo would first invoke the pre-conditions of [A, B, D, E, C], in that particular order, and eventually runs the pre-condition of the concrete implementation Foo.


_10
let foo = Foo()
_10
foo.test()

Above will print:


_10
A
_10
B
_10
D
_10
E
_10
C
_10
Foo

Similarly, for post-conditions, the same linearization of interfaces would be used, and the post-conditions are executed in the reverse order. For example, replacing the pre conditions in the above example with post conditions with the exact same content would result in an output similar to:


_10
Foo
_10
C
_10
E
_10
D
_10
B
_10
A