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

Goal: Accept partial initialization + use of records created via such #54987

Open
pnkfelix opened this issue Oct 11, 2018 · 6 comments

Comments

Projects
None yet
6 participants
@pnkfelix
Copy link
Member

commented Oct 11, 2018

Spawned off of #21232

In the long-term, we want to accept code like this:

struct S { x: u32, y: u32 }
fn main() { let mut s: S; s.x = 10; s.y = 30; a_use_of(&s); another_use_of(s); }
fn a_use_of(_s: &S) { /* ... */ }
fn another_use_of(_s: S) { /* ... */ }

We probably also want to start accepting this too:

struct S { x: u32, y: u32 }
fn main() { let mut s: S; s.x = 10; a_use_of_field(s.x); }
fn a_use_of_field(_x: u32) { /* ... */ }

(But that second example is more debatable. I don't think there's any debate about the first example.)


See #54986 for the short-term goal of rejecting all partial initializations until we can actually use the results you get from partial initialization.

@leonardo-m

This comment has been minimized.

Copy link

commented Oct 11, 2018

fn main() { let mut s: S; s.x = 10; a_use_of_field(s.x); }

If there's an invariant of the struct fields you can't use one struct field before all of them are initialized.

@Havvy Havvy added T-lang and removed T-lang labels Oct 11, 2018

@pnkfelix

This comment has been minimized.

Copy link
Member Author

commented Oct 11, 2018

I think @leonardo-m 's previous comment is meant to be an argument against accepting the code snippet they quoted.

Here are my main responses to that:

  • Usually if there's some sort of invariant of the fields in a struct, it is enforced via privacy. (I.e., by making the fields non-pub, and making sure your public API upholds the invariant of interest.) This feature has no effect on that methodology.
  • One big instance where struct invariants are super important is destructors: You don't want to get into a situation where a struct is only partially initialized and then its destructor gets called. Or rather, if the language allowed that, it would be basically impossible to write the code for a destructor. Rust already has a rule ensuring that you cannot move out of the fields of an ADT that implements Drop. This feature has no effect on that rule, either.

@pnkfelix pnkfelix added the A-NLL label Oct 11, 2018

@Centril Centril added the T-lang label Oct 11, 2018

@pnkfelix

This comment has been minimized.

Copy link
Member Author

commented Oct 16, 2018

tagging as NLL-deferred because we know we aren't going to try to implement this as part of the 2018 edition.

@pnkfelix

This comment has been minimized.

Copy link
Member Author

commented Dec 21, 2018

@Centril has an in-progress draft of an RFC here: Centril/rfcs#16

@pnkfelix

This comment has been minimized.

Copy link
Member Author

commented Dec 21, 2018

Re-triaging for #56754. P-low since any change here deserves a (currently "unwritten" or at least unposted) RFC.

@jethrogb

This comment has been minimized.

Copy link
Contributor

commented May 1, 2019

There are some concerns about the current state of this in #60450

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.