Rust: Tracking issue for RFC 1682: field init shorthand

[aturon]

RFC.

Before stabilizing:

• [x] Needs documentation (https://github.com/rust-lang/rust/issues/38830)

[Havvy]

Once we have this syntax, we'll want to clean up the compiler where it's useful. Since this would be almost a rote cleanup, we'd either want a mentored issue or a tool to do it.

[steveklabnik]

a tool to do it.

I wonder if @killercup 's rustfix could do this

[eddyb]

@steveklabnik rustfmt doing it by default has also been mentioned. cc @nrc

[nrc]

Yeah, Rustfmt could def. do this.

[killercup]

I haven't read that RFC; if you can write a lint that suggests the new
syntax (with a concrete and valid code suggestion), rustfix will be able to
fix this. (If this is only a syntactic change though it might indeed make
more sense to add this to rustfmt.)

Eduard-Mihai Burtescu [email protected] schrieb am Sa. 22. Okt.
2016 um 09:54:

@steveklabnik https://github.com/steveklabnik rustfmt doing it by
default has also been mentioned. cc @nrc https://github.com/nrc

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/rust-lang/rust/issues/37340#issuecomment-255513712,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AABOX5MshoHk0m8Wn4KIr1eC4p3DInQpks5q2cFCgaJpZM4KdxM6
.

[est31]

I think that the compiler shouldn't lint for this, suggesting sugar features is more a thing for clippy.

[chriskrycho]

What's the current status on this—in nightly, it looks like, via https://github.com/rust-lang/rust/issues/11994? Do we know when it's expected to land?

[matthew-piziak]

@chriskrycho Confirmed—it works in nightly. I'm using the feature in my nightly project right now.

[Havvy]

The new documentation required RFC means we need to figure out how to document it, I think?

• The grammar needs updating
• as would adding a section to the book and the new book.
• The reference would need a paragraph explaining the sugar.
• Additionally, we may want to add examples to Rust By Example showing the syntax.

We also need changelog entries? I propose the following for the short entry. I don't have the energy right now to try a long entry.

Added field init shorthand syntax when the field and variable names match.

[matthew-piziak]

Rustfmt also needs support for this feature. The tracking issue is here. I'm planning to tackle that eventually but I'm not going to lick the cookie just yet.

[nikomatsakis]

I opened https://github.com/rust-lang/rust/issues/38830 to specifically track adding docs.

[brson]

Can we nominate this for FCP now in expectation that it will be finished in time to branch 1.16 on Feb 2?

[nikomatsakis]

@rfcbot fcp merge

I propose that we stabilize field init shorthand. It's handy and uncomplicated. One remaining work item is documentation, which is being tracked by #38830, but work has already begun.

[rfcbot]

Team member @nikomatsakis has proposed to merge this. The next step is review by the rest of the tagged teams:

• [x] @aturon
• [x] @eddyb
• [x] @nikomatsakis
• [x] @nrc
• [x] @pnkfelix
• [x] @withoutboats

Concerns:

• documentation-unfinished resolved by https://github.com/rust-lang/rust/issues/37340#issuecomment-272295405

Once these reviewers reach consensus, this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[nrc]

Reluctantly, and assuming documentation is finished before we stabilise.

[withoutboats]

@rfcbot reviewed

@nrc RFC 1636 requires that we document every feature before we actually stabilize it.

[pnkfelix]

@rfcbot concern documentation-unfinished

(Despite the point just made by @withoutboats, I see no reason to put my check mark on something whose required documentation is unfinished.)

[est31]

@pnkfelix

I see no reason to put my check mark on something whose required documentation is unfinished.)

There has been some discussion about this question in the thread to stabilize custom derive.

quoting @steveklabnik :

My imagining of this was always that the decision to stabilize and the actual stabilization are separate. That is, @rust-lang/lang can say "this can be made stable", but the commit to remove the gate also ensures the documentation exists.

Given that we just had a release, my plan was to do something like this:

1. Wait for this to leave FCP
   
   
   
   1. Land some docs. (I was planning on writing them in this case)
   
   
   2. Make the stabilization PR.
   
   

Possibly combining two and three.

In my opinion, it would make sense to separate the two decisions as it allows for a cleaner transition. E.g. you can't merge a docs PR if you don't know whether something will be stabilized (docs are intended for the users, no? They should, in the best case, always match what is actually stable), but if there is no FCP, how do you know whether it will actually be stabilized.

[aturon]

@est31 I entirely agree. The review here is purely to go into FCP, which still leaves several weeks before stabilization could even occur; the check for documentation should happen separately, later. That will give us the highest throughput.

[pnkfelix]

I can see the throughput argument.

But I am having difficulty making this argument jibe in my head with the fact that RFC's now have a section on "how this will be taught to new users" ... so I thought we were transitioning to a world where docs were required earlier on before we make final decisions on them.

Anyway, fine, I don't actually care enough to hold up the process.

[pnkfelix]

@rfcbot resolved documentation-unfinished

[pnkfelix]

@rfcbot reviewed

[aturon]

Manually marking for FCP.

[rfcbot]

:bell: This is now entering its final comment period, as per the review above. :bell:

psst @nikomatsakis, I wasn't able to add the final-comment-period label, please do so.

[rfcbot]

The final comment period is now complete.

[lambda-fairy]

Now that #39459 has landed, I think there's nothing blocking stabilization at this point.

[est31]

@lfairy I'm not sure, #38830 is still open, no?

[est31]

Hmm... seems @lfairy is right: the documentation RFC doesn't require that the feature is documented in Rust by example. So all the points required for stabilisation are done (see the list in #38830), which means we can stabilize it!

[aturon]

We're ready to go forward with stabilization!

[chriskrycho]

Easy enough to add an example anyway. I needed a little win today!