Changing Struct Literals

[iopq]

While this affects the type ascription RFC, it is a good thing to do even if type ascription is not implemented until later. Other considerations are raised like record types and keyword argument syntax.

(rendered)

[phaux]

The way I thought of it would look like:

struct Point {
    x => i32,
    y => i32,
}

let Point{x => first: i32, y => second: i32} = Point{x => 1, y => 2};

But in general, we are on the right track with this RFC.

You could throw some assert!s here and there to show what is the resulting state.

assert!(first == 1);
assert!(second == 2);

[ghost]

I prefer the way it's written in the RFC. In terms of judgements, it's pretty natural to think of x: A = y as x: A followed by x = y. The other way around is less clear. Should it be interpreted as (x = y) : A or x = y followed by y: A or like the original but reversed: x = y followed by x: A? Also, there's precedent with let x: A = y.

[phaux]

You're only confused, because you still don't see the difference between an assignment and a struct literal and using = doesn't help.

Structs in patterns are defined as something like this (changed : to => for sake of clarity):

pattern ::= StructName "{" (field_name "=>" pattern)* "}"

And then type ascription RFC extends pattern with pattern ::= pattern ":" type

That's why it should go {field => variable: Type}. It's in line with the current type ascription RFC.

[theemathas]

I think that the design constraints should be moved to the motivation section. Additionally, alternative syntaxes should be in the alternatives section (maybe as a list comparing the proposed designs). The "detailed design" section should only contain exactly one syntax design, the one that you prefer.

Putting things in logical places makes it easier to read the RFC.

[CloudiDust]

+1 to the Point {.x = 1, .y = 2} syntax and I agree that this RFC needs some reorganization.

[ghost]

Another 👍 to the Point {.x = 1, .y = 2} syntax.

[theemathas]

I prefer the syntax proposed by @phaux : Point { x => 1, y => 2: i32 } and struct Point { x => i32, y => i32 }

Note that the syntax that uses = looks backwards when destructuring.

[petrochenkov]

I'm generally in favor of the C99 syntax (with or without dots), but I don't believe it can be accepted given that abiding the 1.0 timeline is treated above everything else.

[theemathas]

@petrochenkov there is a new schedule for 1.0 http://blog.rust-lang.org/2015/02/13/Final-1.0-timeline.html

[pnkfelix]

@theemathas do note this important section of that blog post:

Is there risk of slippage by not moving to beta now?

It seems unlikely. Essentially all of the language and library features needed for 1.0 have already landed, meaning that we will have 12 weeks of time to polish between alpha2 and 1.0 final.

[phaux]

@pnkfelix I was also opposed to changing the syntax, but it turns out it would make sense to change it, bacause it clashes with some features planned for post-1.0.

[CloudiDust]

@petrochenkov, I think this is a simple syntax change that can be introduced along with a deprecation period for the old syntax, as both can coexist for a while. So if it is accepted, we have enough time to settle on the new syntax.

@theemathas, I agree in patterns = feels backwards, but => is a bit too "heavy weight" for me. Also, struct Point { x => i32, y => i32 } is using => to specify types, which is doing :'s job IMHO. I understand that it is trying to follow the "initialization syntax should follow type definition syntax" rule, but I prefer only using : for specifying types.

Point {.x = 1, .y = 2} doesn't follow that rule, but it looks like a C99 designated initializer, so I believe this is fine.

@pnkfelix, thanks for the reminder. The biggest problem with the current struct syntax is that with type ascription, there will be ambiguities. Is {a: Foo} a block (which returns a of type Foo), or is it part of a struct definition/initializer/pattern?

I remember avoiding such ambiguities is one of the reasons that Foo {bar: Baz} is preferred to Foo {bar = baz} currently, so if Foo {bar: Baz} itself would have such a problem, we should change it.

[theemathas]

@CloudiDust I am also OK with another syntax if you don't want => to be used for types: Point { x => 1, y => 2: i32 } and struct Point { x: i32, y: i32 }. The problem here is that it is quite a bit inconsistent.

However, I think that the =>-everywhere syntax is OK, since I think of a struct as a "dictionary/hashmap that has identifiers as the keys and values as the data". In the declaration of structs, the type annotations are for the data, not the keys.

[pnkfelix]

(my comment was not meant to be taken as an argument against this proposal; it was more a knee-jerk reaction to the two comments preceding it.)

On its face I actually have no problem with inserting a period before field names, i.e. Foo { .bar = <expr> } and Foo { .bar = <pat> }, as proposed (I think) by this RFC; if anything, it emphasizes the non-hygienic nature of field names.)

By the way, here is an unresolved question the RFC might pose: should the pattern binding syntax now be Foo { <pat> = .bar }, putting the pattern on the left-hand-side of the source? (We should be able to parse both <pat> = .bar and .bar = <pat> in the short-term, and emit a warning telling the author to switch to the correct one.)

[steveklabnik]

I am 👎 on making such a big change at this point in development, and also, on the specific changes itself. I strongly prefer the current syntax.

[phaux]

There's also another flaw in reasoning of the proponents of designated-initializer-like syntax.
In C there is no such thing as "struct literal". I agree that Rust could get designated initializers and they could be used as simple sugar:

// a Point struct is being assigned to the variable p
// there is a single assignment and one `=` operator
let p = Point { x => 0, y => 0 };
// this is a sugar for two assignments and we have two assignment operators
p { x = 0, y = 0 };
// this desugars to
p.x = 0;
p.y = 0;

They're appropiate for Rust in general, but they shouldn't replace struct literals, bacause they serve different purpose. This is a tiny detail that most people don't realize.

@pnkfelix

should the pattern binding syntax now be Foo { <pat> = .bar }, putting the pattern on the RHS of the source?

With => syntax and type ascription the pattern would still be { field_name => subpattern : Type }, where the subpattern can obviously be a variable name which will get the matched value assigned to.

[CloudiDust]

@theemathas, I think all alternatives will have their own inconsistencies somewhere so this is about subjective preference.

But compared to inconsistencies, ambiguities are more objective problems, which I believe should be addressed no matter which alternative we choose.

@pnkfelix, I am not sure which one to prefer, on one hand, Foo { .bar = <expr> } is the "construction order" that every other pattern follows, on the other hand Foo { <expr> = .bar } is more natural. I personally don't find "backwards assignment" a problem, but I can see why others would.

@steveklabnik, if we can find a non-hackish way to deal with the ambiguities that will be introduced by type ascription, then I am also fine with the current syntax.

[phaux]

@steveklabnik We all want type ascription and to keep current struct syntax, but unfortunately we can't have both.

[pnkfelix]

@CloudiDust please note that I was talking in my proposed question about patterns, not expressions. I do not see the expression Foo { <expr> = .bar } as natural.

[theemathas]

@pnkfelix How do you propose to write a struct pattern? How do you propose to write a struct expression?

[pnkfelix]

@theemathas as I said in the comment, either Foo { <pat> = .bar } or Foo { .bar = <pat> } works for the generalized form, its just a matter of choosing one, AFAICT.

(For the shorthand when the pattern is just an identifier that has the same name as the field, I assume we would continue doing Foo { bar }, as today, with no leading period.)

But I was really just trying to post a point to the RFC author, not cause extensive bikeshedding on a relatively minor detail.

[CloudiDust]

@pnkfelix, sorry for the typo, I mean <pat> above.

Currently I slightly prefer Foo { <pat> = .bar } to Foo { .bar = <pat> }.

However, given that this is a quite subjective matter, I hope we can find a way to have both the current struct syntax and type ascription without future hacks.

[steveklabnik]

@phaux I'd take the struct literal syntax over ascription.

[theemathas]

@CloudiDust @steveklabnik Do you two mean something like let x = Foo { 1 = .bar };? It looks horribly ugly. (1 is a valid pattern IIRC)

[phaux]

@steveklabnik I was thinking the same way, but then I realized that keeping the syntax would also close the door to much more features that we would want in the future. Think about it, it's just a syntax, but it limits the possibilities so much. The = vs => could be considered bikeshedding (I think that = also has some limitations), but I think we can all agree that : has to go if we want to open the door for more features in the future.

[CloudiDust]

@theemathas No, I mean:

let x = Foo { .bar = 1 };
let Foo { baz = .bar } = x; // Now local variable `baz` has value 1.

But I think this is not very pretty either.

Also I believe you mean @pnkfelix, not @steveklabnik.

[jakerr]

I'm also -1 on changing the syntax. I think it's good now and type ascription is not needed so often that it should govern a change to struct-literal syntax.

Please correct me if I'm wrong but I believe the naive syntax for type ascribed struct literals is at least non-ambiguous and useable:

Foo { x: a: Bar, y: c: Baz }

Whether it is pretty is certainly up for debate... though I think the time for that is long past.

On the bright side we can make this prettier with tools like syntax-highlighting and conventions. For example removing the spaces around the ascribing : make the above nicer looking in my opinion.

Foo { x: a:Bar, y: c:Baz }

Or if you really feel like it's too confusing put some parenthesis around the ascribed expression:

Foo { x: (a: Bar), y: (c: Baz) }

[theemathas]

@CloudiDust what about match? Is it match x { Foo { .bar = 1 } => ... } or match x { Foo { 1 = .bar } => ... }?

[CloudiDust]

@theemathas Oops.

I believe if we do Foo { <pat> = .bar } then it will be match x { Foo { 1 = .bar } => ... }.

Maybe we should allow both after all? (Looks like it's going out of control.)

@jakerr, there will be a parsing ambiguity with {x: Foo} as I said above.

I am wondering if it is possible to tweak the current struct syntax a little so {x: Foo} will not be ambiguous in the future.

[tbu-]

I think all alternatives will have their own inconsistencies somewhere so this is about subjective preference.

Well that's a great way to stop the discussion of alternatives.

[bvssvni]

For example, you could use the current syntax:

WindowSettings {
  title: "Hello world!".to_string(),
  samples: 0,
  size: [300, 300],
  fullscreen: false,
  exit_on_esc: true
}

and => as a "keys on left side, values on right side":

WindowSettings {
   title, samples, size, fullscreen, exit_on_esc =>
   "Hello world!".to_string(), 0, [300, 300], false, true
}

Named argument syntax would be similar, and allow type ascription with =>:

foo(x: 3, y: 4)
foo(x, y => 3, 4)
foo(x, y => 3: i32, 4: i32)

[phaux]

try to write Point3D { (.x, .y) = point2d, .z = 0 } in it.

I think that there's no need for introducing such complicated syntax, but I don't have strong opinion on this one. I propose:

Point3D { x, y, z =>> point2d.x, point2d.y, 0 }
// shorthand for
Point3D { x => point2d.x, y => point2d.y, z => 0}

Anyways, this will need a separate RFC, so we can discuss it later.

@bvssvni I would rather like to get rid of : in structs completely. I'd propose the => syntax as a simple replacement for : as one RFC and then take the discussion about a,b=>>c,d vs (a,b)=>(c,d) to discourse.

[CloudiDust]

@bvssvni, I'd prefer abandoning the current literal syntax and aim for more consistency if we are to introduce the => sugar.

@phaux, I am in favor of introducing ()s instead of a new operator =>>. ()s are also more consistent with the existing tuple pattern syntax and more clearly delimited. (Does =>> match greedily?)

Also, both a, b =>> c, d and (a, b) => (c, d) are important ergonomics gain over the a => b, c => d syntax if we have many fields to assign. Without such sugar, the => syntax would have a disadvantage compared to the current one. They are strong arguments in favor of the change, and should be part of this RFC.

[phaux]

I wrote another RFC: #866

[pnkfelix]

team discussed struct syntax at weekly meeting.

@pnkfelix attempted to present the most conservative change being proposed by the RFC (namely C99-style adding leading periods to field names and then using .foo = expr), and present the proposal in the best light possible (though internet connectivity problems led to him being cut-off a little early).

response seemed unanimously opposed to changing the struct syntax, and the argument was not solely based on schedule; @pcwalton argued largely based on precedent set by other languages, e.g. JS, which is also adding type ascription via :.

So I think that this RFC is likely to be simply closed.

[bvssvni]

@pnkfelix I'm reading through the old RFC of why = can't be used instead. I'm still tripping over this, and I've used Rust for 1 year.

[bvssvni]

@pnkfelix After a quick read-through, it seems the old RFC was rejected mainly because of 1) a parser ambiguity and 2) it was too late. Some ideas was suggested to solve the parser ambiguity, but I'm not capable to tell whether it is solvable.

My major concern is the conflict between named argument syntax and type ascription. I don't see this discussed much and would appreciate this being settled before 1.0.

It is not the end of the world, but it sticks out as part of the language that "doesn't feel right". At this point, things have been relatively stable, so I don't think going through one extra round of upgrading is a big deal. I'm for changing this, probably not to => because I think plain = feels more intuitive. Unfortunately there is the parser ambiguity.

[pnkfelix]

@bvssvni all I can tell you is that most of the core team members were present at the weekly meeting ; some were strongly opposed to changing the syntax (and obviously did not think that using = was any more intuitive than :), and none present were interested in championing the proposal.

[bvssvni]

I've read through the comments and the RFC once more and made up my mind.

+1 to the .foo = expr idea represented in this RFC, with : for declaration, in the most conservative form.

This syntax can later be extended to @eddyb 's idea with tuples. It solves the ambiguity problem. It also works well with auto complete in text editors, which is often trigger by .. It is more lightweight than => and uses = for assignment, which I find intuitive.

One question: Why are JS used as argument for keeping the syntax, but C99 extension against? They are both precedences but no reason is given why one is good and the other is bad.

I think the use-follows-declaration rule seems a bit artificial, as I think of it as simple assignment and then = comes first to my mind. People probably have different preferences here.

Rust is still a great language as it is, but if I imagine myself in a world without pressure of releasing it then I'm in favor of this RFC. Of course the core team got my full sympathy. It would be surprise if this went through so close to 1.0, but thanks to @iopq for writing this up!

[rkjnsn]

I am strongly in favor of changing struct literals (without changing struct definitions). I realize there are trade-offs, consistency-wise, but by far the most consistent seeming to me is to use : solely to specify types.

I don't think what JS, Ruby, and Python do is important here. They are all dynamically-typed languages, and don't have important (and likely ambiguous, with type ascription) other uses for them. They're also not an area that Rust is targeting.

It would be very nice to allow the type of struct literals to be inferred in the future, and even to have anonymous structs. Neither of these would be possible using if struct syntax stays the same and type ascription is introduced. Type ascription is important, and : is the obvious and consistent choice, given how it is used everywhere else in the language aside from struct literals. The same cannot be said of struct literals, and thus it is they that should change.

Thus, I find it very important to change struct-literal synax, regardless of what syntax is chosen.

That said, by far my favorite syntax is { .x = 5, .y = 10 }. This has a number of advantages, as has been noted elsewhere:

• Matches C99 designated initializers (unlike JS et al, this is an area Rust is targeting)

• Not ambiguous with block expressions. Would enable struct literals to be used in places they are not currently allowed due to ambiguities. In the face of inferred struct literals and type ascription, can be disambiguated from a block expression with a single token look-ahead for a period.

• Drives auto-completion in IDEs. Typing the . would allow the IDE to immediately pop up a list of fields.

• It's much clearer during destructuring which identifier is the field name, since it is preceded by a dot. (I think the field name should go on the left.)

• Provides a potential syntax for allowing multiple fields to be updated at once:

  let mut c = Circle { .x = 3, .y = 7, .radius = 2 }
  // Later we want to move the circle, keeping the radius the same
  c { .x = 9, .y = 5 }
  

  This works even if private fields are present, unlike functional updates

• Uses = for binding a value, as with let

Ideally, this would be the only supported syntax, but since 1.0 is fast approaching, and there is a strong desire not to break the world, the old syntax could be retained and deprecated, with the new syntax preferred. Potential new features such as inferred struct literals would require the programmer to use the new form to avoid ambiguity. (This could even be done post 1.0)

Also, to respond to @pcwalton's comment that "Even JS has gone with : for type ascriptions". I only see this as indicating that using : for type ascription is highly desirable, not that overlap isn't painful. It certainly isn't enough to conclude that they wouldn't go back and change the existing features to use something else, if they could.

[steveklabnik]

by far the most consistent seeming to me is to use : solely to specify types.

Today's Rust also uses : for trait inheritance, so this would still not be true.

[koeninger]

@steveklabnik inthat case the name to the right of the colon is still type-level, not value-level, correct?

[phaux]

@steveklabnik It would be still more consistent for : to specify types or traits depending on context than to specify types/traits/values sometimes in the same context.

@pcwalton Typescript uses : for objects, because it's a superset of JS. We don't have this limitation.

[rkjnsn]

Today's Rust also uses : for trait inheritance, so this would still not be true.

It's still in the context of types. Using : for specifying types, trait inheritance, and type-parameter bounds all seems consistent to me, while using it for values does not.

[CloudiDust]

@rkjnsn, I propose another syntax: Point {.x: 5, .y: 10}.

(If an identifier is prefixed by ., than the : after it means value binding, otherwise it means type ascription.)

It has the following advantage compared to Point {.x = 5, .y = 10}:

1. A less radical change, only adding dots is necessary, which means it should be more acceptable for those who prefer the visual appeal of Foo {x: 5, y: 10}. Also this is very important if we are to do breaking changes at this stage.
2. Point {.x: foo, .y: bar} doesn't feel like reversed assignments in patterns.

Disadvantages:

1. No other language that I can currently think of uses this syntax. (But I don't think this will feel foreign to anyone.)
2. Technically, : is still multi-purposed in structs. (But .ident: can be seen as a whole.)

But I think c { .x = 9, .y = 5 } is still good for doing multi-updates.

[pnkfelix]

@CloudiDust I strongly suspect those who object to switching syntax are not going to see Point { .x: 5, .y: 10 } as being any more acceptable than Point { .x = 5, .y = 10 }.

From what I can tell, this seems to be about some sort of inertia (i.e., objections about "so much churn!") and/or attachment to Javascript style syntax (perhaps based on the recognition that the latter is familiar to a very large population of modern programmers).

---

(Regarding whether this situation is analogous to what we went through with int/uint; some people see the situations as the same; others see the shift to isize/usize as preventing real bugs, as opposed to being an aesthetic issue. Aesthetic motivations seem quite unlikely to sway people at this stage.)

[CloudiDust]

@pnkfelix, the .ident: syntax is chosen because it may stand a chance against those two types of objections:

The change is simply adding .s, not changing :s to =s or =>s. That means less typing.

Also, the latter two alternatives are (more) heavier weight, and people may dislike the loss of a lightweight syntax.

But {.x: 5, .y: 10} don't look too different from the javascript style syntax that we currently use, if anything, the prefixing . signifies which is the field name and which is the bound variable in patterns.

I can see why people may still say no to this change though.

Examples are in the comments of #866.

[rkjnsn]

Aesthetic motivations seem quite unlikely to sway people at this stage.

If the sole reason for wanting this change were "this other syntax looks slightly prettier", then I'd agree that it would be a pointless change at this point. However, it has many more advantages, as I outlined above.

[CloudiDust]

I tried to come up with an RFC for .ident:. But after comparing the current syntax with the alternatives in various contexts, I'd say even .ident: fails to match the current one in the succinctness department, in most situations. (See comments in #866 for the comparisons. Especially, it seems that, even type-inferred struct literals and named arguments are not strong enough reasons against the current syntax.)

The theoretical advantages of the alternatives may not actually translate into practical advantages.

[bvssvni]

I discovered that optional arguments through struct sugar conflicts with .foo = bar syntax in left expressions. foo = bar means setting foo to bar if not specified, which is different than .foo = bar that means mapping to the variable bar.

Then there is a problem with baking in optional arguments into the language. Part of the motivation to have named argument syntax is optional arguments, but since Option is so common, it leads to subtleties:

foo(None); // does this mean the value is not specified, or did we explicitly want `None`?
foo(,); // does this mean the same as the one above, or something else?

Leaving out an optional argument when calling a function is different than passing None.

Since optional argument has slightly different semantics than Option, it might lead to more confusion introducing optional arguments than just using Option everywhere. It will sacrifice ergonomics for more explicit syntax.

If we don't plan to add optional arguments, some of the motivation to have named arguments falls away, and therefore some of the motivation of changing struct initialization syntax.

We might still benefit from changing to .ident = expr in other ways, like auto completion and tuple syntax, but those weren't my major concerns.

We might just keep :, and forget about named arguments and optional parameters.

[phaux]

@bvssvni I imagine default arguments as types implementing Default trait. Gist

[bvssvni]

@phaux That looks nice!

The idea won't work for named argument syntax, because all the arguments must be treated as an anonymous struct that implements Default as a whole. Default requires all members of a struct to have a default value. Also, when refactoring to a struct, the default values are attached to the type instead of the called function, which means you have to look up two places in documentation to see what the function does.

There are slightly changes in the semantics here that makes a huge difference for refactoring. It destroys the 1:1 mapping between struct initialization and optional arguments. You have to think of the arguments as a struct, not as ordinary optional parameters. The alternative is baking it into the language, but that would collide with current practice of Option, because the semantics is similar but not equivalent, and will lead to confusion and inconsistent feel across new and old libraries.

The old struct sugar RFC solved this problem, but now that we get ambiguity with either type ascription or .ident = expr, this probably won't happen. We can add sugar for inferred structs or something, but it won't have as much payoff in refactoring/ergonomics.

Therefore, we might as well just keep : and forget "true" named and optional parameters, and add some sugar for Default post 1.0. As there is no huge ergonomic win of changing struct syntax, this removes lot of my motivation to change it.

[rkjnsn]

@CloudiDust It's true that Point {.x = 5, .y = 10} is a little less succinct, but I think it more than makes up for it with it's other advantages. Among many others, I find it easier to read, and it avoids points of confusion and ambiguity (both mentally and technically).

[CloudiDust]

@rkjnsn, personally I think the loss of succinctness is acceptable (and the (.x, .y) = (1, 2) syntax can help here) and "reversed assignments" in patterns don't bother me. But this may not be a view that is shared by enough people, especially at this stage.

[nrc]

Sadly, changes to struct literal syntax at this stage are not possible. Even if there were a perfect new syntax, the level of disruption at this late stage would be hard to justify. In particular, there is not any technical clash with type ascription, only potential confusion. Since type ascription should be rare, that does not justify such a large change. There are also many people who like the current syntax (not me, actually, I much prefer =, but such is life) since it has precedence amongst other reasons, and no proposed new syntax is widely approved of and problems can be found with all of them.

[flying-sheep]

i get the “too low gain/disruption ratio” argument, but there’s one thing i don’t get:

no proposed new syntax is widely approved of and problems can be found with all of them

could you tell us what the problem with the following syntax is and how it is not widely approved?

struct Point { x: u8, y: u8 }
// or
struct Point { .x: u8, .y: u8 }

// …

let p = Point { .x = 5, .y = 10 };

let Point { a = .x, b = .y } = p;

[seanmonstar]

Regarding "widely accepted", I know for myself I have largely ignored this
RFC cause I knew there was no way it would change. I imagine others did
likewise. So, the RFC is likely missing plenty of opinions on which
syntaxes are horrible and which are not.

On Fri, Feb 27, 2015, 4:13 AM flying-sheep [email protected] wrote:

i get the “too low gain/disruption ratio” argument, but there’s one thing
i don’t get:

no proposed new syntax is widely approved of and problems can be found
with all of them

could you tell us what the problem with the following syntax is and how it
is not widely approved?

struct Point { x: u8, y: u8 }
// or
struct Point { .x: u8, .y: u8 }

// …

let p = Point { .x = 5, .y = 10 };

let Point { a = .x, b = .y } = p;

—
Reply to this email directly or view it on GitHub
#841 (comment).