RFC: Add syntaxic sugar for struct expressions fields from variables of the same name

[rust-highfive]

Issue by SimonSapin
Sunday Feb 02, 2014 at 12:29 GMT

For earlier discussion, see rust-lang/rust#11990

This issue was labelled with: A-parser, B-RFC in the Rust repository

---

The general syntax for a struct pattern is:

StructName { field_name: new_variable_name }

But when the desired variable name is the same as the field name, it does not need to be repeated:

let MyStruct { name } = struct_value;
do_something_with(name);

This proposal is to add similar syntax sugar for struct expressions:

let name = …;
let struct_value = MyStruct { name };

… would be the same as:

let name = …;
let struct_value = MyStruct { name: name };

CC: @eddyb

[SimonSapin]

This was discussed in https://github.com/rust-lang/meeting-minutes/blob/master/weekly-meetings/2014-02-11.md#binding-in-struct-patterns

There were some concerns about ambiguities in e.g. for x in Foo { x } { }, but the grammar was changed since then (I think?) so that the desugared form of this would not be valid either.

fn main() {
    struct Foo { x: () }
    impl Iterator<()> for Foo {
        fn next(&mut self) -> Option<()> { None }
    }
    let x = ();
    for i in Foo { x: x } { }
}

a.rs:7:21: 7:22 error: expected one of `;`, `}`, found `:`
a.rs:7     for i in Foo { x: x } { }

CC @nick29581

[theemathas]

Is this still unambiguous with type ascription?

[chris-morgan]

@theemathas: it is still unambiguous; the full form of struct initialisation is defined appropriately so that type ascription works, and the additional, simpler form that this permits cannot have any colons (it’s commas and identifiers only), so there is no interaction with the type ascription feature.

[pnkfelix]

So, this feature was suggested (rust-lang/rust#11990) and then prototyped ( rust-lang/rust#11994 ) back in February 2014

The team collectively declined to adopt the feature for Rust 1.0 : rust-lang/rust#11990 (comment) (again, back in Febuary 2014).

But then in June 2014, we accepted RFC 92, that restricted the use of struct literals to only appear in certain expression positions.

• RFC text: https://github.com/rust-lang/rfcs/blob/master/text/0092-struct-grammar.md
• RFC PR: Disallow struct literals in ambiguous positions. #92 (May 2014)
• Implementation: libsyntax: Disallow struct literals after if, while, match, and rust#14885 (also June 2014)

I believe that with the restriction specified by RFC 92, we could readily add this feature to the language backwards compatibly; that is, the parsing ambiguity issues are no longer present, I think.

• Parsing ambiguity was the primary reason we declined to do this according to https://github.com/rust-lang/meeting-minutes/blob/master/weekly-meetings/2014-02-11.md#binding-in-struct-patterns
• There were other more abstract reasons also discussed there (e.g. is such a form "hygienic"), but I think all those points are debatable. In particular, even king of hygiene @dherman said "it's such great sugar that it's hard to avoid"

I'm going to assign this to myself as a reminder to try to draft up a formal RFC for it at some point in the (hopefully near) future.

[SimonSapin]

Sounds great, thanks for championing this Felix!

[KalitaAlexey]

In feature we will have feature Rename variable which will break code or should be insert field name.

[pnkfelix]

@KalitaAlexey I infer you are talking about an IDE feature.

I think the language design should not hinder itself on how IDE features are to be implemented

[petrochenkov]

@pnkfelix
Any updates? Do you still plan to write an RFC?
Since implementation is trivial, it's only a matter of decision.

[pnkfelix]

@petrochenkov I've been distracted. Anyone else is free to draft up an RFC; I won't be upset if that happens.

[petrochenkov]

This is implemented and stabilized in rust-lang/rust#39761
ping @SimonSapin @pnkfelix for closing