Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Begin documenting initialization checking #2174

Closed
wants to merge 4 commits into from

Conversation

arielb1
Copy link
Contributor

@arielb1 arielb1 commented Oct 15, 2017

If we're going to have a spec for the borrow checker, it shouldn't leave out important components.

Edit: Rendered

this is not particularly pretty, but I believe it complies with the
union RFC and it doesn't appear to create much conflict.
text/2094-nll.md Outdated
- supporting prefixes were defined earlier
- so: reading a path like `a` is illegal if `a.b` is mutably
borrowed, but -- in contrast with shallow accesses -- reading `a` is also
illegal if `*a` is mutably borrowed


And the accessed data and all children in its lvalue tree must be definitely initialized.
Copy link
Contributor

Choose a reason for hiding this comment

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

Is this sentence fragment supposed to be connected to the "3." bullet point immediately above, or something higher up?

@arielb1
Copy link
Contributor Author

arielb1 commented Oct 16, 2017

cc @pnkfelix

@arielb1
Copy link
Contributor Author

arielb1 commented Oct 16, 2017

cc @nikomatsakis

```Rust
let x: (u32, u32);
x.0 = 4;
x.1 = 5;
Copy link
Contributor

Choose a reason for hiding this comment

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

In the current borrow checker, we do not accept this program. Are there corner cases that I am overlooking here?

Presuming there are not, I think that the current borrow checker basically enforces a rule like "Assigning to an lvalue LV requires that all prefixes of LV are definitely initialized", right?

Maybe we should just adopt this rule for now?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This is indeed a difference from the current borrow checker. I see no problem with this rule.

@Centril Centril added the T-lang Relevant to the language team, which will review and decide on the RFC. label Dec 5, 2017
@nikomatsakis
Copy link
Contributor

I think I'd like to move these changes over to /~https://github.com/nikomatsakis/nll-rfc/ -- I still view that as the 'official home' of the NLL RFC, at least until stabilization.

@aturon
Copy link
Member

aturon commented Feb 7, 2018

@nikomatsakis What do you want to do with this RFC?

@pnkfelix
Copy link
Member

I'm going to try to follow @nikomatsakis 's request and turn this PR into a PR against /~https://github.com/nikomatsakis/nll-rfc/ ; after I have created that second PR, I will close this one.

@pnkfelix
Copy link
Member

pnkfelix commented Apr 9, 2018

Okay as promised (too long ago) I have trivially ported ariel's hard work over to nikomatsakis/nll-rfc#51

I did not attempt to fill in any of the todo's in the text; that can happen over on the nll-rfc repo.

Closing as any future work should happen over there.

@pnkfelix pnkfelix closed this Apr 9, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
T-lang Relevant to the language team, which will review and decide on the RFC.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants