Update status for Cadence FLIPs

cadence/20211129-cadence-mutability-restrictions.md

@@ -1,5 +1,5 @@
 ---
-status: implemented
+status: released
 flip: 703
 authors: Daniel Sainati (daniel.sainati@dapperlabs.com)
 sponsor: Daniel Sainati (daniel.sainati@dapperlabs.com)

cadence/20211208-cadence-remove-optional-reference.md

@@ -1,5 +1,5 @@
 ---
-status: implemented
+status: released
 flip: 722
 authors: Daniel Sainati (daniel.sainati@dapperlabs.com)
 sponsor: Daniel Sainati (daniel.sainati@dapperlabs.com)

cadence/20211208-cadence-storage-api-changes.md

@@ -1,5 +1,5 @@
 ---
-status: implemented
+status: released
 flip: 718
 authors: Daniel Sainati (daniel.sainati@dapperlabs.com)
 sponsor: Daniel Sainati (daniel.sainati@dapperlabs.com)

cadence/20211210-cadence-numeric-supertypes.md

@@ -1,5 +1,5 @@
 ---
-status: implemented
+status: released
 flip: 729
 authors: Supun Setunga (supun.setunga@dapperlabs.com)
 sponsor: Supun Setunga (supun.setunga@dapperlabs.com)

cadence/20220203-capability-controllers.md

@@ -1,5 +1,5 @@
 ---
-status: implemented
+status: released
 flip: 798
 authors: Janez Podhostnik (janez.podhostnik@dapperlabs.com), Bastian Müller (bastian@dapperlabs.com)
 updated: 2024-06-26
@@ -565,18 +565,18 @@ Existing links and capabilities need to be migrated.
 ### Migration of storage links
 
 Each existing storage link is dereferenced to its *target storage path* (`/storage`).
-To determine the target storage path, the link's *source capability path* (`/public` or `/private`) 
+To determine the target storage path, the link's *source capability path* (`/public` or `/private`)
 is followed until a storage (`/storage`) path is encountered.
 
 For each valid link, a new Storage Capability Controller will be issued.
-If the source path is public (`/public`), the resulting capability gets published. 
+If the source path is public (`/public`), the resulting capability gets published.
 
 Note that it is not necessary for the storage path to contain any value at the time of migration.
 
 ### Migration of account links
 
 For each existing account link a new Accout Capability Controller will be issued.
-If the source path is public (`/public`), the resulting capability gets published. 
+If the source path is public (`/public`), the resulting capability gets published.
 
 ### Migration of capabilities
 

cadence/20220516-reference-creation-semantics.md

@@ -1,5 +1,5 @@
 ---
-status: implemented
+status: released
 flip: 941
 authors: Daniel Sainati (daniel.sainati@dapperlabs.com)
 sponsor: Daniel Sainati (daniel.sainati@dapperlabs.com)

cadence/20220708-resource-reference-invalidation.md

@@ -1,5 +1,5 @@
 ---
-status: implemented
+status: released
 flip: 1043
 authors: Supun Setunga (supun.setunga@dapperlabs.com)
 sponsor: Supun Setunga (supun.setunga@dapperlabs.com)
@@ -120,7 +120,7 @@ Developers will have to update their code to remove the use of references to mov
 If they still want a reference to the resource after move, they will have to obtain a new reference.
 
 ### Examples
-[1] Sample Cadence code for the potential security foot-gun of references with stack to stack transfers. 
+[1] Sample Cadence code for the potential security foot-gun of references with stack to stack transfers.
 ```cadence
 access(all) contract Buyer {
 

cadence/20220715-cadence-purity-analysis.md

@@ -1,5 +1,5 @@
 ---
-status: implemented
+status: released
 flip: 1056
 authors: Daniel Sainati (daniel.sainati@dapperlabs.com)
 sponsor: Daniel Sainati (daniel.sainati@dapperlabs.com)

cadence/20220725-cadence-borrowContract.md

@@ -1,5 +1,5 @@
 ---
-status: implemented
+status: released
 flip: 1071
 authors: Deniz Mert Edincik (deniz@edincik.com)
 sponsor: Austin Kline (austin@flowty.io)

cadence/20220908-publish-claim-capability.md

@@ -1,5 +1,5 @@
 ---
-status: implemented
+status: released
 flip: 1122
 authors: Daniel Sainati (daniel.sainati@dapperlabs.com)
 sponsor: Daniel Sainati (daniel.sainati@dapperlabs.com)

cadence/20220921-attachments.md

@@ -1,5 +1,5 @@
 ---
-status: implemented
+status: released
 flip: 11
 authors: Daniel Sainati (daniel.sainati@dapperlabs.com)
 sponsor: Daniel Sainati (daniel.sainati@dapperlabs.com)

cadence/20221011-for-loop-semantics.md

@@ -1,5 +1,5 @@
 ---
-status: implemented
+status: released
 flip: 13
 authors: Bastian Müller (bastian@dapperlabs.com)
 sponsor: Bastian Müller (bastian@dapperlabs.com)

cadence/20221018-change-fun-type-syntax.md

@@ -1,5 +1,5 @@
 ---
-status: implemented
+status: released
 flip: 43
 authors: Naomi Liu (naomi.liu@dapperlabs.com)
 sponsor: Naomi Liu (naomi.liu@dapperlabs.com)

cadence/20221024-interface-inheritance.md

@@ -1,5 +1,5 @@
 ---
-status: implemented
+status: released
 flip: 40
 authors: Supun Setunga (supun.setunga@dapperlabs.com)
 sponsor: Supun Setunga (supun.setunga@dapperlabs.com)

cadence/20221207-authaccount-capabilities.md

@@ -1,5 +1,5 @@
 ---
-status: implemented
+status: released
 flip: 53
 authors: Bastian Müller (bastian@dapperlabs.com)
 sponsor: Dieter Shirley (dete@dapperlabs.com)

cadence/20230417-events-emitted-from-interfaces.md

@@ -1,5 +1,5 @@
 ---
-status: implemented
+status: released
 flip: 111
 authors: Deniz Mert Edincik (deniz@edincik.com) / Supun Setunga (supun.setunga@dapperlabs.com)
 sponsor: Deniz Mert Edincik (deniz@edincik.com) / Supun Setunga (supun.setunga@dapperlabs.com)
@@ -41,18 +41,18 @@ Suppose the `FungibleToken` is a contract, and has a `TokenWithdrawal` event dec
 
 With function pre/post conditions being able to emit events, the `withdraw` function would look like below.
 
-```cadence 
+```cadence
 pub contract FungibleToken {
-   
+
     pub event TokenWithdrawal(type: Type, amount: UFix64, from: Address?)
-   
-    pub resource interface Provider{ 
-        pub fun withdraw(amount: UFix64): @{FungibleToken.Vault} { 
-            post { 
+
+    pub resource interface Provider{
+        pub fun withdraw(amount: UFix64): @{FungibleToken.Vault} {
+            post {
                 result.balance == amount: "Withdrawal amount must be the same as the balance of the withdrawn Vault"
-                emit TokenWithdrawal(type:type, amount:amount, from:from) 
-            } 
-        } 
+                emit TokenWithdrawal(type:type, amount:amount, from:from)
+            }
+        }
     }
 }
 ```

cadence/20230503-improve-conformance.md

@@ -1,5 +1,5 @@
 ---
-status: implemented
+status: released
 flip: 83
 authors: Supun Setunga (supun.setunga@dapperlabs.com)
 sponsor: Supun Setunga (supun.setunga@dapperlabs.com)
@@ -11,7 +11,7 @@ updated: 2023-06-19
 ## Objective
 
 This FLIP proposes to relax a restriction associated with interface conformance,
-by allowing conditions defined in other interfaces to coexist with a default function implementation coming from a 
+by allowing conditions defined in other interfaces to coexist with a default function implementation coming from a
 different interface.
 
 ## Motivation

cadence/20230505-remove-priv-and-pub.md

@@ -1,9 +1,9 @@
 ---
-status: implemented 
+status: released
 flip: 84
 authors: Daniel Sainati (daniel.sainati@dapperlabs.com)
 sponsor: Daniel Sainati (daniel.sainati@dapperlabs.com)
-updated: 2023-05-05 
+updated: 2023-05-05
 ---
 
 # FLIP 84: Remove `pub` and `priv` aliases for access modifiers
@@ -12,53 +12,53 @@ updated: 2023-05-05
 
 This FLIP proposes to remove the `pub` alias for `access(all)` and the `priv`
 modifier for `access(self)`, requiring all code to use these longer forms instead
-of the shortened ones. 
+of the shortened ones.
 
 This also proposes to remove the `pub(set)` access keyword, which was previously used to make
-variables publicly settable. This is not a common case, and in order to simplify the language, 
+variables publicly settable. This is not a common case, and in order to simplify the language,
 we also propose to remove it. If users wish to have a field be publicly settable, they should write
-a public mutator function for that field. 
+a public mutator function for that field.
 
 ## Motivation
 
-The proposed entitlements changes in [the entitlements FLIP](https://github.com/onflow/flips/pull/54) 
-will add a new `access(X)` modifier for entitled access, which will likely be used frequently 
+The proposed entitlements changes in [the entitlements FLIP](https://github.com/onflow/flips/pull/54)
+will add a new `access(X)` modifier for entitled access, which will likely be used frequently
 in many contracts. It would be more consistent with this new `access(X)` syntax for `pub`
-and `priv` to be `access(all)` and `access(self)` respectively. 
+and `priv` to be `access(all)` and `access(self)` respectively.
 
 ## User Benefit
 
-This will increase the readability and consistency of user code. 
+This will increase the readability and consistency of user code.
 
 ## Design Proposal
 
-The proposal is simple: just remove the `pub` and `priv` aliases. `pub(set)` will 
-also be removed. 
+The proposal is simple: just remove the `pub` and `priv` aliases. `pub(set)` will
+also be removed.
 
 ### Drawbacks
 
 This will increase the verbosity of all code, as well as break every single contract
-that exists, as it is extremely unlikely that there is any code on Mainnet currently that 
+that exists, as it is extremely unlikely that there is any code on Mainnet currently that
 does not use at least one `pub` modifier. However, as discussed in the next section, this may be
-an benefit rather than a drawback. 
+an benefit rather than a drawback.
 
 Additionally, any existing `pub(set)` fields will need to be replaced with `access(all)` fields, and be given
 a setter function explicitly in order to regain their previous functionality.
 
 ### Compatibility
 
-This is not backwards compatible, and will indeed break every existing contract. However, 
+This is not backwards compatible, and will indeed break every existing contract. However,
 given that the aforementioned entitlements change is also going to require a rewrite of all
 code currently deployed to Mainnet, a change such as this that statically breaks all of that code
 will alert developers that changes are required, rather than allowing potentially newly unsafe
-code to slip through undetected. 
+code to slip through undetected.
 
 ### User Impact
 
-This is going to require all code to be updated to not use the deprecated modifiers. It would 
+This is going to require all code to be updated to not use the deprecated modifiers. It would
 be possible to write a migration assistant that would automatically replace the `pub` and `priv`
 modifiers with their equivalent long forms, but it is unclear if we would want to do this, given
 that a stated goal of this change is to make developers manually consider which `pub` methods are
-truly `access(all)` and which should be rewritten to use entitlements. 
+truly `access(all)` and which should be rewritten to use entitlements.
 
 ## Questions and Discussion Topics

cadence/20230505-remove-restricted-types.md

@@ -1,5 +1,5 @@
 ---
-status: implemented 
+status: released
 flip: 85
 authors: Daniel Sainati (daniel.sainati@dapperlabs.com)
 sponsor: Daniel Sainati (daniel.sainati@dapperlabs.com)
@@ -14,49 +14,49 @@ Currently in Cadence, a restricted type consists of a type (often confusingly al
 the restricted type) and a set of interface types that serve as its restrictions. Written `T{I1, I2, ...}`,
 this type indicates a value of type `T`, but restricted such that only members present on one of the `I`s
 can be accessed. This FLIP proposes to remove the `T` portion of the type, changing this type to simply
-indicate some value of a type that conforms to each of the `I`s.  
+indicate some value of a type that conforms to each of the `I`s.
 
 ## Motivation
 
 The proposed entitlements changes in [the entitlements FLIP](https://github.com/onflow/flips/pull/54) make
 restricted types mostly useless in their current form. Previously they existed as a form of access control for references,
-as a restricted reference type could not be downcast, so a restriction set functioned for references like access control, 
+as a restricted reference type could not be downcast, so a restriction set functioned for references like access control,
 limiting what functionality was available to a reference.
 
-The entitlements changes will move this functionality to entitlements, and allow downcasting references, making 
-this behavior unnecessary. However, it will still be valuable to allow the specification of "interface set" types, 
+The entitlements changes will move this functionality to entitlements, and allow downcasting references, making
+this behavior unnecessary. However, it will still be valuable to allow the specification of "interface set" types,
 for the purposes of polymorphism, so by removing the outer `T` component of the restricted type `T{I1, I2, ...}`, we
-can replace this obseleted type form with a simpler interface set type that handles the polymorphism use case. 
+can replace this obseleted type form with a simpler interface set type that handles the polymorphism use case.
 
 ## User Benefit
 
-This will simplify the language by removing a redundant and poorly understood feature. 
+This will simplify the language by removing a redundant and poorly understood feature.
 
 ## Design Proposal
 
-This would remove the "restricted type" portion of the restricted type. Users will no longer be able to write types with a `T` in 
-the `T{I}` position of an old restricted type. 
+This would remove the "restricted type" portion of the restricted type. Users will no longer be able to write types with a `T` in
+the `T{I}` position of an old restricted type.
 
-For the new semantics of the interface set type, we can use the existing semantics of the `AnyStruct{X}` and `AnyResource{Y}` restricted types, 
-as these contain no information about the type being restricted, and thus function only as restrictions on a generic type. 
+For the new semantics of the interface set type, we can use the existing semantics of the `AnyStruct{X}` and `AnyResource{Y}` restricted types,
+as these contain no information about the type being restricted, and thus function only as restrictions on a generic type.
 
-The semantics of upcasting and downcasting restricted types will remain the same; they will be covariant in their interface sets. 
+The semantics of upcasting and downcasting restricted types will remain the same; they will be covariant in their interface sets.
 
-Existing references and capabilities could be migrated by replacing the restricted type with the outer type, i.e. converting `T{I}` to `T`. 
+Existing references and capabilities could be migrated by replacing the restricted type with the outer type, i.e. converting `T{I}` to `T`.
 In combination with the incoming entitlement changes, where the old "restricted" behavior would be recaptured with entitlements, this would
 be able to preserve existing behavior. In particular, in the case of references, the entitlements present on the interfaces would be granted to the
-reference type. 
+reference type.
 
 For example, an existing `&Vault{Withdraw}` value would be migrated to a `auth(Withdrawable) &Vault` reference
 
 ### Drawbacks
 
-This is not backwards compatible, and will break existing restricted types that have non-trivial values for their outer type. 
+This is not backwards compatible, and will break existing restricted types that have non-trivial values for their outer type.
 
 ### Alternatives Considered
 
 We could simply leave restricted types as-is, which would break nothing, but would leave restricted types in the language
-as a vestigial feature without much of a use case. 
+as a vestigial feature without much of a use case.
 
 ### Compatibility
 

cadence/20230517-member-access-semnatics.md

@@ -1,5 +1,5 @@
 ---
-status: implemented
+status: released
 flip: 89
 authors: Supun Setunga (supun.setunga@dapperlabs.com)
 sponsor: Supun Setunga (supun.setunga@dapperlabs.com)
@@ -13,7 +13,7 @@ updated: 2023-07-05
 This proposal suggest to return a reference when accessing a member of a container (field of a composite value,
 key of a map, index of an array), if the parent value is also a reference and the accessed member is a container type.
 
-## Motivation   
+## Motivation
 
 A previous version of Cadence ("Secure Cadence") restricted the potential foot-gun of mutating container-typed
 `let` fields/variables via the
@@ -88,7 +88,7 @@ var id: String = collection.id
 
 #### Case II: Code only has a reference to the container value
 
-Assume a reference to the collection `collectionRef` is available, and is of type `&Collection`. 
+Assume a reference to the collection `collectionRef` is available, and is of type `&Collection`.
 i.e. code doesn't own the value, but has only a reference to the value.
 
 ```cadence
@@ -118,7 +118,7 @@ pub resource MasterCollection {
 
 pub resource Collection {
     pub var ownedNFTs: @{UInt64: NonFungibleToken.NFT}
-    
+
     access(Withdraw) fun withdraw(withdrawID: UInt64): @NonFungibleToken.NFT {
         let token <- self.ownedNFTs.remove(key: withdrawID) ?? panic("missing NFT")
         emit Withdraw(id: token.id, from: self.owner?.address)
@@ -140,8 +140,8 @@ Previously, it was possible to withdraw from the inner collection, despite the `
 masterCollectionRef.kittyCollection.withdraw(24)    // OK
 ```
 
-With the proposed changes, this will be an error, since `masterCollectionRef.kittyCollection` is now return a 
-non-auth reference, and calling `withdraw` is prohibited because that reference doesn't have the `Withdraw` entitlement. 
+With the proposed changes, this will be an error, since `masterCollectionRef.kittyCollection` is now return a
+non-auth reference, and calling `withdraw` is prohibited because that reference doesn't have the `Withdraw` entitlement.
 
 ```cadence
 masterCollectionRef.kittyCollection.withdraw(24)    // Static Error