Stream: ideas

Topic: `+=` for record updating

Fletch Canny (Dec 29 2023 at 23:57):

Hi! I think I have a few more points in favor of updating the record update syntax.

The main reason I think = would be better than : is because we could introduce +=, -=, *=, and /=. They would not make as much sense with :, like +:. Although changing : to = isn't really necessary. I understand the minimal feature set Roc wants to provide, but I think this would be good for 2 main reasons:

• It encourages longer, more descriptive names. When I have to write { someLongRecordName & someLongFieldName: someLongRecordName.someLongFieldName + 1 } it temps me to instead give them shorter names that are harder to understand, like { r & f: r.f + 1}. I think the alternative is a nice middle ground { someLongRecordName & someLongFieldName += 1 }.
• It's got the familiarity for those coming from other languages who would want such a feature, which is part of the reason we use : in the first place.

I do think that it's a bit limited, since it only applies to arithmetic operators, and there could be an alternative syntax which is more general { r & f (binaryFunc)= value } which desugars to { r & f = binaryFunc r.f value } but that kinda diminishes my second main point as to why this is a good idea in the first place.

Also as for the consistency argument

in Roc today:

• always, what comes before = is a pattern
• always, an identifier followed by a : is a record field declaration
• always, an identifier followed by a blank space and then a : is a type declaration

Wouldn't it be more consistent from the programmer's perspective to say something like

• always, = proceeds a pattern
• always, patterns in record declaration/updating must be identifiers
• always, an identifier followed by a : is a type declaration
  although this is probably less consistent to the parser. For example-

Changing it to = would create syntax ambiguities. Sometimes = would be preceded by a pattern, and other times by a record field label that doesn't introduce anything into scope, and there would be no local syntactic difference between them; you'd have to search for context clues in the surrounding code to tell which it was.

I'm not sure how Roc is parsed but what issues does this cause? Is it slower parsing? I'm guessing it doesn't lead to an actually ambiguous syntax since other languages do this, but I'm not sure.

Also just as a side note, would & be better as $? $ doesn't have a meaning that people will already assume, AFAIK it's not used anywhere else in the language, it's easier to reach on an american QWERTY keyboard, and visually it's similar enough to leave your code aesthetically unchanged (however much that matters). Could also be @ for similar reasons.

Anton (Dec 30 2023 at 10:01):

small sidenote: $ is planned to be used for shadowing, @ is used for opaque types.

Fletch Canny (Dec 30 2023 at 12:40):

Thanks! That's good to know. I'm glad that shadowing is going to be implemented because there are many times I have to rename stuff and it can be frustrating

Last updated: Jun 16 2026 at 16:19 UTC