Tracking issue for RFC 2102, "Unnamed fields of struct and union type"

[Centril]

This is a tracking issue for the RFC "Unnamed fields of struct and union type" (rust-lang/rfcs#2102).
The feature gate for the issue is #![feature(unnamed_fields)].

About tracking issues

Tracking issues are used to record the overall progress of implementation.
They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.

Steps

• Implement the RFC (see Tracking issue for RFC 2102, "Unnamed fields of struct and union type" #49804 (comment) for mentoring instructions)
• Adjust documentation (see instructions on forge)
• Formatting for new syntax has been added to the Style Guide (nightly-style-procedure)
• Stabilization PR (see instructions on forge)

Unresolved questions

• The RFC was accepted ages ago, and implementation turned out a lot harder than what was likely anticipated. As written, the RFC adds a fundamentally new "kind of type" to the language that's a hybrid of a struct and a union, with non-trivial consequences across many parts of the compiler (and the language, e.g. for macros accessing all fields of a type). Also see the discussion here, these meeting notes, and this comment.

Implementation history

• Parse unnamed fields and anonymous structs or unions (no-recovery) #115131
• Lowering unnamed fields and anonymous adt #115367
• Add more checks for unnamed_fields during HIR analysis #121198
• Retire the unnamed_fields feature for now #131045

[joshtriplett]

@Centril Regarding unresolved questions: the first three paragraphs in that section are just talking about the future possibility of full unnamed types that can appear everywhere, which would be the subject of a future RFC. The last paragraph talks about other future possibilities that also need their own RFCs.

[Centril]

@joshtriplett Yeah; that was also my interpretation, so ==> no unresolved questions?

[cramertj]

Looks like this still needs an implementation

[igotfr]

I think It, I hope it helps

RFC #2870

think it would be better that way

let unamedstruct: { count: i32, price: f64, type: u8 } = { count: 500, price: 6.4, type: 1 };

or

let unamedstruct: Struct = { count: 500, price: 6.4, type: 1 };

or simply

let unamedstruct = { count: 500, price: 6.4, type: 1 };

nothing to do with tuples, starting with tuples having no named elements, structs yes

[joshtriplett]

@cindRoberta That's an unrelated proposal. This RFC is about unnamed fields within other types, not fully general anonymous types.

[ibraheemdev]

Is there any movement on this, or is it just waiting for someone to implement it?

[varkor]

This is still waiting on an implementation.

[ibraheemdev]

@varkor maybe mentoring instructions would help someone get started?

[varkor]

I don't have time to write up full mentoring instructions at the moment, but if someone is interested in implementing this feature, I am happy to provide pointers for how to get started on Zulip.

• The first place I'd look is parse_name_and_ty in compiler/rustc_parse/src/parser/item.rs, where you'll want to start parsing an underscore, along with the rest of the syntax for unnamed fields as described in the RFC.
• This will entail modifying StructField in compiler/rustc_ast/src/ast.rs to contain one of two types: either a NamedStructField (containing most of what StructField currently contains) along with an UnnamedStructField, whose structure should be evident from the description in the RFC.
• Having done this, you should gate the new feature by creating a new unnamed_fields feature gate in compiler/rustc_feature/src/active.rs, which should be added to INCOMPLETE_FEATURES, and then checking for UnnamedStructField in compiler/rustc_ast_passes/src/feature_gate.rs.
• This should cover at least up to Parsing in the RFC.