Tracking issue for RFC 1682: field init shorthand #37340
Comments
aturon
added
B-RFC-approved
|
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. |
I wonder if @killercup 's |
|
@steveklabnik |
|
Yeah, Rustfmt could def. do this. |
|
I haven't read that RFC; if you can write a lint that suggests the new Eduard-Mihai Burtescu notifications@github.com schrieb am Sa. 22. Okt.
|
|
I think that the compiler shouldn't lint for this, suggesting sugar features is more a thing for clippy. |
Implement field shorthands in struct literal expressions. Implements #37340 in a straight-forward way: `Foo { x, y: f() }` parses as `Foo { x: x, y: f() }`. Because of the added `is_shorthand` to `ast::Field`, this is `[syntax-breaking]` (cc @Manishearth). * [x] Mark the fields as being a shorthand (the exact same way we do it in patterns), for pretty-printing. * [x] Gate the shorthand syntax with `#![feature(field_init_shorthand)]`. * [x] Don't parse numeric field as identifiers. * [x] Arbitrary field order tests.
|
What's the current status on this—in nightly, it looks like, via #11994? Do we know when it's expected to land? |
|
@chriskrycho Confirmed—it works in nightly. I'm using the feature in my nightly project right now. |
|
The new documentation required RFC means we need to figure out how to document it, I think?
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.
|
|
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. |
|
I opened #38830 to specifically track adding docs. |
|
Can we nominate this for FCP now in expectation that it will be finished in time to branch 1.16 on Feb 2? |
nikomatsakis
added
the
T-lang
|
Team member @nikomatsakis has proposed to merge this. The next step is review by the rest of the tagged teams: Concerns:
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. |
|
Reluctantly, and assuming documentation is finished before we stabilise. |
|
@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.) |
There has been some discussion about this question in the thread to stabilize custom derive. quoting @steveklabnik :
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. |
|
@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. |
|
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. |
|
@rfcbot resolved documentation-unfinished |
|
@rfcbot reviewed |
|
Manually marking for FCP. |
aturon
added
the
final-comment-period
|
🔔 This is now entering its final comment period, as per the review above. 🔔 psst @nikomatsakis, I wasn't able to add the |
|
The final comment period is now complete. |
|
Now that #39459 has landed, I think there's nothing blocking stabilization at this point. |
|
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! |
|
We're ready to go forward with stabilization! |
|
Easy enough to add an example anyway. I needed a little win today! |
Stabilize field init shorthand Closes rust-lang#37340. ~Still blocked by the documentation issue rust-lang#38830.~ EDIT: seems that all parts required for stabilisation are fixed, so its not blocked.
…=<try> use field init shorthand in src/librustc/ Commentary on #37340 [suggested](#37340 (comment)) using the new field init syntax in the compiler. Do we care about this? If so, here's a pull request for the librustc/ directory. While [`rustfmt` might do this in the future](#37340 (comment)), in the meantime, some simple Python will do: ```python #!/usr/bin/env python3 import os, re, sys OPPORTUNITY = re.compile(r" (\w+): \1,?\n") def field_init_shorthand_substitution(filename): with open(filename) as f: text = f.read() revised = OPPORTUNITY.sub(r" \1,\n", text) with open(filename, 'w') as f: f.write(revised) def substitute_in_directory(path): for dirname, _subdirs, basenames in os.walk(path): for basename in basenames: field_init_shorthand_substitution(os.path.join(dirname, basename)) if __name__ == "__main__": substitute_in_directory(sys.argv[1]) ``` **Update 3 July**: edited the search (respectively replace) regex to ` (\w+): \1,?\n` (` \1,\n`) from ` (\w+): \1,` (` \1,`)
…=estebank use field init shorthand in src/librustc/ Commentary on #37340 [suggested](#37340 (comment)) using the new field init syntax in the compiler. Do we care about this? If so, here's a pull request for the librustc/ directory. While [`rustfmt` might do this in the future](#37340 (comment)), in the meantime, some simple Python will do: ```python #!/usr/bin/env python3 import os, re, sys OPPORTUNITY = re.compile(r" (\w+): \1,?\n") def field_init_shorthand_substitution(filename): with open(filename) as f: text = f.read() revised = OPPORTUNITY.sub(r" \1,\n", text) with open(filename, 'w') as f: f.write(revised) def substitute_in_directory(path): for dirname, _subdirs, basenames in os.walk(path): for basename in basenames: field_init_shorthand_substitution(os.path.join(dirname, basename)) if __name__ == "__main__": substitute_in_directory(sys.argv[1]) ``` **Update 3 July**: edited the search (respectively replace) regex to ` (\w+): \1,?\n` (` \1,\n`) from ` (\w+): \1,` (` \1,`)
ghost
mentioned this issue
RFC.
Before stabilizing:
The text was updated successfully, but these errors were encountered: