Skip to content

Conversation

@roxelo
Copy link
Member

@roxelo roxelo commented Jul 5, 2021

Copy link
Member Author

@roxelo roxelo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@arora-aman I think there are a few things we want to change. Mainly wording


Regardless of if the data will be read by the closure, i.e. in case of wild card patterns, if a variable defined outside the closure is mentioned within the closure the variable will be captured in its entirety.

## Other traits difference
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we can actually delete this section. This is because the modified rules stated "the captured values" and we already clarified in the earlier Edition2018 subsection that the values captured are variables that are captured in its entirety

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm fine removing it

}
### Capturing references in move contexts

Rust doesn't allow moving fields out references as a result in the case of move closures, when the closure takes ownership of a path, it will only take ownership of a prefix of path that runs up until the first dereference (this may be the entire path if there are no dereferences in the path).
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

moving fields out of

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Instead of truncate ... we reborrow the data being accessed throw the reference


Regardless of if the data will be read by the closure, i.e. in case of wild card patterns, if a variable defined outside the closure is mentioned within the closure the variable will be captured in its entirety.

## Other traits difference
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm fine removing it

@roxelo roxelo force-pushed the closure-doc branch 5 times, most recently from 37ce76c to bc0e50c Compare July 9, 2021 00:16
@arora-aman arora-aman force-pushed the closure-doc branch 4 times, most recently from 880405c to 0a9323a Compare July 20, 2021 09:06
carols10cents and others added 12 commits July 20, 2021 20:45
This should be the other form of its.
The phrase 'may not' could mean 'might not' or 'is not allowed to'.
The original sentence could mean that "its destructor is run" and "it is dropped" are two separate possibilities, rather than two names for the same action.
It is not clear if the original intended to mean these as two separate
concepts, or synonyms for the same thing.
ehuss added 3 commits July 28, 2021 13:45
array-expr.md: fix typo; 'polish' sentence
…rcion

Mention "function item type to `fn pointer`" coercion
@arora-aman arora-aman force-pushed the closure-doc branch 2 times, most recently from 92336ed to 6b88e48 Compare August 2, 2021 09:14
workingjubilee and others added 21 commits August 3, 2021 00:29
Allow users to change status labels
expressions.md: Attempt fixing broken grammar in Mutability paragraph
There are definitions of subtrait and supertrait, so use the
official terminology.
…rtrait-subtrait

Use subtrait/supertrait, not sub-trait, super-trait.
Co-authored-by: Josh Triplett <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.