Implement field shorthands in struct literal expressions.

[eddyb]

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).

• Mark the fields as being a shorthand (the exact same way we do it in patterns), for pretty-printing.
• Gate the shorthand syntax with #![feature(field_init_shorthand)].
• Don't parse numeric field as identifiers.
• Arbitrary field order tests.

[huonw]

This is a (nice) syntax change, and so should get some discussion of some sort.

[alexcrichton]

I'm surprised how easy that was to add!

I've added this to the meeting agenda (I'll put my vote in favor of it though).

[alexcrichton]

One possible ambiguity issue that we've come up with on IRC:

for x in Foo { a } { b }

[huonw]

Maybe we could just allow omitting the field name, but not the colon:

let (some_field, other_field) = (1, 2);

for x in Foo { : some_field, : other_field } { ... }

... but that looks rather peculiar.

[eddyb]

@huonw the ambiguity only shows up with one-field structures. How often have you seen Foo {a: a}?
In that case, adding another comma (as with one-tuples) is not that big of a problem if you really want to use the shorthand - Foo {a,} is still shorter.

[huonw]

We'll need a few tests for the comma thing too.

[SimonSapin]

Even though it leaves a distasteful inconsistency in the language, for x in Foo { a } { b } seems rare enough that I don’t mind resolving the ambiguity by having the struct-expression syntaxic sugar not apply here.

[alexcrichton]

We decided in today's meeting that due to ambiguities and some hygiene related concerns that we don't want this for now. Perhaps in rust 2.0!

[SimonSapin]

Sad panda. Why as late as 2.0, isn’t it backward-compatible?

[alexcrichton]

Ah I should clarify by 2.0 I mean "after 1.0" perhaps. We didn't concretely decide for a time for something like this to come in, we decided that now isn't the time for it though.

[huonw]

(Sorry for the spam: phone touchscreen leads to "pocket commenting" :( )

[ben0x539]

Wouldn't be an ambiguity if we had ( ) in our for and if etc expressions like some other curly braces languages. :)

[SimonSapin]

Too bad. I find myself often writing code ending like this:

SchemeRelativeUrl { userinfo: userinfo, host: host, port: port, path: path }

Where each field has be computed earlier. This sugar would make it much nicer.

As to the ambiguities, they only occur in cases where (IMO) it’s rare to have a literal struct expression.

(I wanted to write up some arguments that didn’t seem to appear in the meeting notes, but I’ll now stop beating this dead horse.)

[pnkfelix]

@SimonSapin This seems trivial to work around for now via macro_rules! :

#[feature(macro_rules)];

macro_rules! struct_fields {
    ($Struct:ident $($field:ident),+ )
        => { $Struct { $($field: $field),+ } } ;
}

struct SchemeRelativeUrl {
    userinfo: ~str,
    host: [u8, ..4],
    port: u32,
    path: ~str
}

fn main() {
    let userinfo = ~"hi";
    let host = [1,2,3,4];
    let port = 56;
    let path = ~"/root/";
    let s = struct_fields!( SchemeRelativeUrl userinfo, host, port, path );
    println!("s: {:?}", s);
}

[SimonSapin]

@pnkfelix This’ll help, thanks. I didn’t think of using a macro. However this doesn’t as easily cover cases where only some fields are based on a variable of the same name:

            Ok(Url { scheme: scheme, scheme_data: OtherSchemeData(scheme_data),
                     query: query, fragment: fragment })

Still, sugar baked into the language is always nicer than a macro you have to define :)

[huonw]

macro_rules! struct_field {
    ($Struct:ident $($short:ident),*; $($long:ident: $long_e: expr)*) => {
        $Struct { $($short: $short, )* $($long: $long_e),* }
    }
}

// ...
struct_fields!(
    Url scheme, query, fragment; scheme_data: OtherSchemeData(scheme_data)
)

[SimonSapin]

Nice! Thanks @huonw. Is the ; necessary to remove ambiguity? Does the macro matcher not backtrack?

[huonw]

It doesn't backtrack (I haven't compiled that so there may actually need to be more disambiguation necessary :( ).

[eddyb]

I'm genuinely curious to know how little needs to be updated here for it to work for #37340.

[KalitaAlexey]

@eddyb I see that in tests you follow the order of fields in a struct. Could you, please, some tests for case like:

struct Foo {
  x: i32,
  y: i32,
}

let x = 5;
let y = 6;
let foo = Foo { y, x };

[petrochenkov]

Ha, this seems to parse shortcuts for numeric fields:

struct S(u8, u8, u8);
let s = S { 0, 1, 2 }; // Parses, 0, 1 and 2 are valid fields, but unresolved identifier expressions

Not sure if this is bad, but this is avoided in pattern parsing by calling parse_field_name only if we detected : ahead.

[petrochenkov]

A feature gate is also probably needed now, it's not 2014 anymore :(

[nrc]

@bors: r+

[bors]

📌 Commit 9908711 has been approved by nrc

[bors]

⌛ Testing commit 9908711 with merge bc283c9...

[bors]

☀️ Test successful - auto-linux-32-nopt-t, auto-linux-32-opt, auto-linux-64-cargotest, auto-linux-64-cross-freebsd, auto-linux-64-debug-opt, auto-linux-64-nopt-t, auto-linux-64-opt, auto-linux-64-opt-rustbuild, auto-linux-64-x-android-t, auto-linux-cross-opt, auto-linux-musl-64-opt, auto-mac-32-opt, auto-mac-64-opt, auto-mac-64-opt-rustbuild, auto-mac-cross-ios-opt, auto-win-gnu-32-opt, auto-win-gnu-32-opt-rustbuild, auto-win-gnu-64-opt, auto-win-msvc-32-opt, auto-win-msvc-64-cargotest, auto-win-msvc-64-opt, auto-win-msvc-64-opt-rustbuild
Approved by: nrc
Pushing bc283c9 to master...