[RFC FS-1049] Nested Record Field Copy and Update Expression

[kerams]

Revived implementation in dotnet/fsharp#14821, (archived) RFC.

[kerams]

With the basic implementation essentially complete, I would like to discuss unresolved questions/the next steps.

Q: What about indexers, e.g.

let anotherPerson1 = { person with A.[3].N = person.A.[3].N + ", k.2" }

I assume this syntax would require that A.[3].N be an expression instead of a long identifier. Is such a change viable from the point of view of the parser? Moreover, replacing an item at a specific position in a collection (perhaps with the exception of Map) does not strike me as a particularly common operation.

For example, using immutable modelling constructs like immutable lists and tuples don't "play well" with this kind of nested update, ideally there would be a way these played nicely with this new syntax

Replacing a tuple element would indeed be much more useful. However, I have no idea how such an intent would be expressed. We could utilize ItemX properties, but that would be a radical change since they are not used elsewhere, not to mention the problematic Rest.

All in all, I am at a loss as to how we could improve the interplay of nested record field updates with other types short of introducing entirely new syntax.

[vzarytovskii]

With the basic implementation essentially complete, I would like to discuss unresolved questions/the next steps.

Q: What about indexers, e.g.

let anotherPerson1 = { person with A.[3].N = person.A.[3].N + ", k.2" }

I assume this syntax would require that A.[3].N be an expression instead of a long identifier. Is such a change viable from the point of view of the parser? Moreover, replacing an item at a specific position in a collection (perhaps with the exception of Map) does not strike me as a particularly common operation.

After discussing it with @dsyme earlier this week, I don't think we want indexers (and setters) to be possible in the nested update syntax at this point.

[T-Gro]

Re. indexers:

If it is an array, it would be unclear whether this mutates the original or not.
If it is a list, it would lead to slow code for values of N that aren't small.

=> I do not think this a good idea to have implicitly.
There is always the possibility to extract the transformation code for the collection into a standalone function, without any new language feature.

[T-Gro]

Re. tuples:

Since there is no lang feature (apart from generating plain function for each position of an n-tuple) to transform tuples even in isolation, it wouldn't feel consistent to have this ability in combination with record.

(i.e. not having special syntax for "updating 4th element of a 7-tuple", but having it when the same tuple is embedded inside a record)

[dsyme]

Yes, my problems are more conceptual - it's a feature that ties more syntax to one particular kind of types. Tricky area as logically the nested update makes sense for other types, there's just no way to express it. It's a bit like pattern matching in this way (hence active patterns were added). Perhaps the solution is active lenses :)

Speaking of which, I guess there's a question whether nested pattern access should also be allowed in matches, for uniformity (but no, you don't need to add this to the RFC, though maybe make a note of it somewhere)

match x with
| { A.B.C=c} ->...