I don't think this potential exists. If in Swift you want to represent a type that
- can be copied, and
- while copying, one or more properties are updated to a new value
then Swift has already a solution, and it's simply using a
struct and making those properties
var: this is how this concept is expressed in the language,
var properties in a
struct mean this, and this is actually a powerful feature that's not present in many other languages, that instead need specialized syntax to represent the simple "copy + update" behavior (while Swift allows for more sophisticated code thanks to the automatic enforcing of value semantics), so failing to understand this critical point will make one not use Swift to its full potential.
As a personal note, in my first years in Swift I completely missed this point, so I get when one doesn't understand it (or stubbornly refuses it, due to familiarity with other languages), but when I "discovered" this feature, I fully embraced it, and then mine and my team's code got better, clearer, safer, faster to write et cetera.
Again, this is a major downside, that should compel us to discard that option altogether, in favor of the closure +
$0 form, which is idiomatic, embedded in the language from the very start, far more flexible, and certainly more appropriate when considering a general extension to the language. Closures +
$0 are here to stay, and I think they should be embraced an leveraged, instead of inventing a new language with constructs that would open the doors to a long stream of sub-pitches to add more features to it in order to make it on-par with the actual existing language.
Circling around this point due to an "allergy" to
$0 (that's not even required, one could just spell the closure input explicitly with a Kotlin-style
it, for example, or
x...) will not help the discussion, so I'd suggest again to instead think about another pitch to replace
$0 with something else (or add another option in case of a single parameter).