A roadmap for improving Swift performance predictability: ARC improvements and ownership control

When minimizing brevity, I personally try to look for redundant information at the point of use. This is distinct from repetition, as the same binding may be used in different roles without being redundant. If I do that with your first example:

I end up with something like

with greatAunt = mother.father.sister {
  // I'm not actually suggesting any language work like this
  greatAunt.[name = "Grace", age = 115]
}

Given the potential to reference things that are not the borrowed value, implicit member syntax seems inappropriate. Unnamed parameters are also unsuitable: the name greatAunt provides additional clarity when reading the code[1].

You could use modifier-chaining, but you probably wouldn't be able to use mutation to do it, thus defeating the purpose of the borrow:

with greatAunt = mother.father.sister {
  // LHS indicates destination, RHS indicates source, no redundancy
  greatAunt = greatAunt
    .name("Grace")
    .age(115)
}

It would also clutter the namespace. Other options include making a list of unary mutating closures then calling each one with greatAunt, but that sort of inversion is why modifier-chaining exists in the first place.

You could probably do something with a sequence of key paths and assigned values, but in this case you'd have different types being assigned to different key paths. That would mean using existential types, which is almost certainly not worth doing.

All of these seem worse than just writing it out. The more times you have to do it, the more likely it is that not having that name would make it harder for someone to understand what it is doing at a glance.


  1. That may not always be the case, but it is here. Besides, it'd be unreasonable to add that only for this construct and not things like if let. ↩︎