4 ms·

This kind of magic sugar may have been spurred by the requirements for SwiftUI and its evolution, in which case, I’m all for it. I can already imagine cases wh

This kind of magic sugar may have been spurred by the requirements for SwiftUI and its evolution, in which case, I’m all for it. I can already imagine cases where callAsFunction() would be handy. For example, having a viewTemplate = SomeView(customization: etc) then creating copies via viewTemplate()

azinman2 7y ago
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...
- Razengan 7y ago
  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.
  - rhysmorgan 7y ago
    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.
  - zionic 7y ago
    Playing code golf with the language syntax isn't the point, clarity and expressiveness is.
oaiey 7y ago
That is the point. Swift has a primary usage unlike other languages. That is okay.
- gilgoomesh 7y ago
  `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.
  - cygx 7y ago
    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.
  - zionic 7y ago
    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.

azinman2 7y ago

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...

Razengan 7y ago
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.
- rhysmorgan 7y ago
  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.
- zionic 7y ago
  Playing code golf with the language syntax isn't the point, clarity and expressiveness is.

oaiey 7y ago

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

gilgoomesh 7y ago
`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.
- cygx 7y ago
  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.
- zionic 7y ago
  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.