You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This adds a new error in the Cadence checker that prevents values like arrays and dictionaries from being mutated outside of the scope they were created in.
Currently, the let declaration kind does not allow writes anywhere, while the var declaration kind allows writes in current and inner scopes. This does not, however, impose any kind of restriction on where dictionary and array values can be mutated, in affect allowing these values to be mutated anywhere they can be read.
This change alters this behavior by only allowing values to be mutated in the context that they can be written. As such, the following program is now an error:
pub struct Foo {
pub let x : [Int]
init() {
self.x = [3]
}
}
pub fun bar() {
let foo = new Foo()
foo.x[0] = 1 // error: cannot mutate `x`: field was defined inside `Foo`
}
A full specification and discussion of this change can be found in this FLIP: onflow/flow#703
This branch with compared with the base branch onflow:master commit d3124c5
The command for i in {1..N}; do go test ./... -run=XXX -bench=. -shuffle=on; done was used.
Bench tests were run a total of 7 times on each branch.
One possible solution for fields with pub(set) access mode is to allow them to be mutated anywhere, the same way that pub(set) var fields can be written to from any scope. The upside of this is that it is simple and easily explainable to users. The possible downside is this does not allow the user to express a field that can be mutated to from any context, but not entirely overwritten (the way that let originally worked). One possible solution to this would be to add a pub(set) let declaration (currently not allowed), that forbids writing to the field in any scope, but allows mutating it in all scopes.
Merging #1267 (01dbc6a) into master (d3124c5) will increase coverage by 0.03%.
The diff coverage is 90.00%.
❗ Current head 01dbc6a differs from pull request most recent head 55be095. Consider uploading reports for the commit 55be095 to get more accurate results
dsainati1
changed the title
Limit mutation of structure fields to the scope of that structure
Limit mutation of container-typed fields to the scope of the composite
Jan 24, 2022
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
dsainati1
changed the title
Closes #1260
Description
This adds a new error in the Cadence checker that prevents values like arrays and dictionaries from being mutated outside of the scope they were created in.
Currently, the
letdeclaration kind does not allow writes anywhere, while thevardeclaration kind allows writes in current and inner scopes. This does not, however, impose any kind of restriction on where dictionary and array values can be mutated, in affect allowing these values to be mutated anywhere they can be read.This change alters this behavior by only allowing values to be mutated in the context that they can be written. As such, the following program is now an error:
A full specification and discussion of this change can be found in this FLIP: onflow/flow#703