But why not just add a method like “.copy()” that’s explicit about what it does? Have to say I’m not a fan of this callAsFunction feature...

Again, because this makes declarative UI cleaner to write, or if you prefer to put it this way: reduces clutter.

I could create button templates then make slightly different copies of those templates without having to subclass Button or attaching .copy()

SwiftUI is all about succinctness.

Why is it all about succinctness? Swift has never been about succinctness - it’s always been about clarity, without over-verbosity. Sometimes, it just takes a decent number of characters to describe something. That’s not necessarily a flaw, especially if it makes something easier to read.

Seeing .copy() makes it much clearer to understand that what I’m receiving is a copy of something.

If you want a Button template, either extend Button with a method taking the parameters you want, or write a curried free function or something. callAsFunction adds absolutely nothing to the language, bar confusion at the call site.

Playing code golf with the language syntax isn't the point, clarity and expressiveness is.

That is the point. Swift has a primary usage unlike other languages. That is okay.

`callAsFunction` is not for Swift's primary usage. It is for Python interop, used by Swift For TensorFlow. Its design is such that you should never need to know it exists unless you're designing your own Python (or other scripting) interop layer.

Then it should be some kind of python-interop module. These kinds of useless syntax hax shouldn't be introduced into the main language. >99% of swift devs will never ever "interop with python", yet they all have to pay the price of this change.

I could see its use in math-heavy code as well. That might be a rather narrow domain, but one where features like this (or operator overloading for another example) do help to reduce syntactic pain.