What’s New in Swift 5.2
hackingwithswift.com
hackingwithswift.com
This time around it's callAsFunction. Yeah, pretty easy to understand in their toy example. When it's deployed IRL with a ton of other things going on, and larger distances between declaration and usage, it looks like a nightmare.
I love writing Swift for myself, but I write it in a pretty boring way. When I have to work with people who get creative and clever, it's awful.
I'm not sure how invested your team is in Swift, but since we do nothing but Typescript, the investment in time (2-3 days for one the lead engineer) tweaking the linter has more than paid off ten-fold in the months since.
This is one of my concerns with adopting Typescript in my team. Would you please share more info about the kinds of things you prohibit, and why you chose them?
I can already imagine cases where callAsFunction() would be handy. For example, having a viewTemplate = SomeView(customization: etc) then creating copies via viewTemplate()
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.
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.
Isn't this more like a problem you have with the team, rather than a problem with the language itself?
That's the same reply that people have to "C++ has too large a surface area". Granted, Swift isn't quite at C++ levels of complexity yet, but ideally, I shouldn't have to cordon off sections of the language I'm using just so my team can stay sane.
I generally love syntax sugar that makes me more productive, cuts out boilerplate, and reduces cognitive overhead... but for me, callAsFunction and even maybe Key Path Expressions as Functions are going to ADD cognitive overhead.
I suppose if I only used Swift, and used it every day, they would be OK, but otherwise it's just more fiddly things that deviate from existing patterns.
Think most agree expressive syntax while minimizing boilerplate is at times going to require sugar. It's interesting you bring cognitive load into the question – perhaps I come at it more from an architectural light than PL fans, but that load seems largely correlated with one's purposes and patterns in using the language.
On that front, Swift has lofty and broad goals (including DSLs), but that surface area doesn't make the language worse. To take your other example, KeyPath Functions don't change anything about KeyPaths; the concept is and remains no different than anywhere else it's implemented (whether in Swift or in another language). Beginners can still use the concept, skill comes with understanding how/why it works, and mastery comes with knowing when/how to use it simply.
If Swift achieves said goals, one needn't be able to understand the last mile of any specific domain where it's used as a language. But it'll be quicker and easier than coming from another language, and the sugar will still be as sweet.
Frankly, it's misleading/silly for me to complain about Swift additions since I don't have the opportunity to write much of it, and primarily only read/consume it with Obj-C code. (I have no choice in this matter.) Basically the language already has a high cognitive load for me, so of course any additions feel burdonsome.
Also, I'm unfamiliar with using KeyPaths like that, so I'm clearly way off on my reaction to them.
The general goals of Swift make me want to learn it better and use it, honestly.
The first time I have to dig into someone's backwards codebase that uses I'm gonna flip.
Objects defining named functions allows you to reason about them logically. Car.tireSizeInches() returns an Int type. Any other developer can see that and know whats up, or type "Car." and explore relevant functionality. What the crap does Car() do? Etc.
This is a huge backwards step for swift syntax. I hope most of the large open source libs ban it.
As for implementation difficulty, see my sibling reply.
If I've got a new team member, I'm not going to put him on async/await. I'm going to find him something simpler to work on.
Or maybe I've been working on a feature for a few months and I need a break to clear my head so I'll work on a smaller feature for a while.
Software development isn't just assembling widgets on an assembly line. It's a creative process. Developers aren't chained to their desks pumping out a non-descript streams of "code" that become different features. Likely incremental time spent on this had almost no real impact on more difficult and useful features.
Sure, but why should this non-feature which makes code harder to read and reason about even be built in the first place? All to save `.parse` at the call site of a parser, for example?
Not relevant to most situations, but I'll just add that this also makes it extremely difficult to teach a language.
I have taught Ruby -- a language with quite a sweet tooth -- for almost twenty years, and I feel like it gets worse and worse every year. Students run off to look at example code online (as they should), but discover that I have been teaching them what seems to them like a different language.
It really leaves me with no choice but to spend a lot of time in lectures saying, "You can do it this way . . . or this way . . . or this way . . . and by the way, these are all semantically equivalent."
Pretend you know nothing about a language, why would you assume .map { $0.thing } and .map(\.thing) are even remotely similar?
The beginner types a declaration of "I want to _____" and the interface uses ML to auto-suggest code. The auto-suggest would be context-sensitive and fit in with previously written code. Auto-correct would work similarly. If the declaration isn't specific enough, then the auto-suggest tool would ask a series of questions that illustrate the different choices a programmer can make in achieving their goal. Finally, the tool would output code that reflects the beginner's choices.
This would increase the speed of the think-do feedback loop. Beginners would be able to jump into coding with very minimal education and "make" the application they want straight away. Of course, it would usually behoove them to eventually read some programming books and take classes, but this tool would pique their interest. The power of the auto-complete would scale back as the beginner progresses unless they get stuck. Maybe this would only work on a finite set of projects that the ML was trained on, which is fine because you can just give a lot of projects to choose from. That is until the ML becomes more powerful and generalizable.
Swift is a lot like Scala. Swift creators, please not repeat Scala's mistakes.
Chances also are that it is inspired by python’s callable (https://en.wikipedia.org/wiki/Callable_object#In_Python), which, as far as I know, people don’t complain about much.
One thing I wish Swift had was an easy way to add more generic functionality. For example, if I want to add drop(), dropWhile(), take(), takeWhile(),... there’s no nice way to extend Array
[1,2,3].take(2)
[“a”,”b”,”c”].take(2)
That’s why I provided two examples containing different types to illustrate what I meant.
I don’t believe you can add a generic function to the array to handle this.
In another repo, I’ve used the FloatingPoint protocol with some luck. However, this should also work with Int’s, for instance:
extension Array where Element: FloatingPoint {
var sum: Element {
self.reduce(0, +)
}
}
What’s wrong with something like this?
extension Array {
func take(_ n: Int) -> ArraySlice<Element> {
self[0..<n]
}
}
[1,2,3].take(2)
[“a”,”b”,”c”].take(2)
[p1,p2,p3].take(2)
That one and the need for generic associatedTypes trip me up all the time.
I think about it every time I see new feature announcements like today's. The opportunity cost of the wasted effort, the new thing that will probably make things harder for everyone. Possibly including those who try to fulfill the generics manifesto.
extension Array {
func take(_ n: Int) -> [Element] {
self[0..<n]
}
}
“Long-term storage of ArraySlice instances is discouraged. A slice holds a reference to the entire storage of a larger array, not just to the portion it presents, even after the original array’s lifetime ends. Long-term storage of a slice may therefore prolong the lifetime of elements that are no longer otherwise accessible, which can appear to be memory and object leakage.”
https://developer.apple.com/documentation/swift/arrayslice
Would it be acceptable to put these implementations in a Functional library?
However, this has nothing to do with generics.If you're willing to sacrifice performance, you could easily write
extension Array {
func take(_ n: Int) -> [Element] {
Array(self[0..<n])
}
} extension Sequence where Element: AdditiveArithmetic {
func sum() -> Element {
return reduce(.zero, +)
}
}I could (and do) say the same thing about Perl.
I have seen something similar before in Python where a class implements __call__, but I have never needed to use it.
The rest look like they aren't worth complicating the language over. Consider:
map(\.name)
map { $0.name }
And what's better... this?
struct Dice {
var lowerBound: Int
var upperBound: Int
func callAsFunction() -> Int {
(lowerBound...upperBound).randomElement()!
}
}
let d6 = Dice(lowerBound: 1, upperBound: 6)
let roll1 = d6()
struct Dice {
var lowerBound: Int
var upperBound: Int
func roll() -> Int {
(lowerBound...upperBound).randomElement()!
}
}
let d6 = Dice(lowerBound: 1, upperBound: 6)
let roll1 = d6.roll()
Default arguments to subscript functions is probably OK. It's better if all kinds of function have the same capabilities.
Language designers seem to underestimate the cognitive overhead of syntax duplication.
StateStream.map { $0.subState }.compactMap(\.subObject).flatMap { $0.objectProperty }
Being correct is super frustrating.
Never underestimate peoples (often irrational) hatred for sigils, or even things that remind them of sigils.
It's for Swift for TensorFlow's integration with Python, in which a bridged Python object can be called as a function. Functions are, of course, objects in Python, so that makes sense, but it would be a pain to have to call fn.call(bar) instead of fn(bar) when fn is a reference to a python object that is a function in its runtime.
It's also used in TensorFlow models, in which callAsFunction() is usually implemented as passing the model's input through all the defined layers in it.
This makes it easy to treat models as if they were functions, which they mathematically are, unlike Dice.
Example:
struct MLP: Layer {
var layer1 = Dense<Float>(inputSize: 2, outputSize: 10, activation: relu)
var layer2 = Dense<Float>(inputSize: 10, outputSize: 1, activation: relu)
@differentiable
func callAsFunction(_ input: Tensor<Float>) -> Tensor<Float> {
let h0 = layer1(input).withDerivative { print("∂L/∂layer1 =", $0) }
return layer2(h0)
}
}
It's a bad example enabled by a bad language feature. Just you wait until answers on stack overflow, sample code, and open source libs are littered with these "bad examples".
Meanwhile, this example is terrible. There is no real need for callAsFunction in your example when you could have added a simple named function on the object to do so. Better yet, you could define a protocol and make sure your layer conforms to said protocol.
Any feature, no matter how good, can be misused. Pointing that out about a specific feature isn't interesting, because it is true of every feature. And the absence of nearly any feature can be worked around, as ultimately all these features compile down to machine code, which doesn't have most features of a high-level language, so the existence of a workaround is also not a very compelling argument.
“Callability” not being restricted to functions (closures or not) can often be convenient, especially when that use is colloquial (eg closure where symbols and collections are callable), and obviate unnecessary boilerplate.
(map (fn [x] (get m x)) a-vec)
(map m a-vec)You have to bind your state to a function exactly once in both cases.
Your example just happens to omit the constructor call required to create the callable object while you are showing the code to create the closure.
Chastised, Anton took his leave from his master and returned to his cell, intent on studying closures. He carefully read the entire "Lambda: The Ultimate..." series of papers and its cousins, and implemented a small Scheme interpreter with a closure-based object system. He learned much, and looked forward to informing his master of his progress.
On his next walk with Qc Na, Anton attempted to impress his master by saying "Master, I have diligently studied the matter, and now understand that objects are truly a poor man's closures." Qc Na responded by hitting Anton with his stick, saying "When will you learn? Closures are a poor man's object." At that moment, Anton became enlightened.
From: http://people.csail.mit.edu/gregs/ll1-discuss-archive-html/m...
Functions are objects in many langages. Python’s specific feature is that there are callable a beyond functions. A class is a callable and a user-defined object can be one despite neither being functions.
Clojure also has that concept.
func die(lowerBound: Int, upperBound: Int) -> () -> Int {
{ (lowerBound...upperBound).randomElement()! }
}
let d6 = die(lowerBound: 1, upperBound: 6)
let roll1 = d6()
But does it really work out? Surely you can't put these new structs into the same arrays as similar lambdas, can you?
Keypaths are used in other places and useful. But they aren’t used very often, and I felt I was forgetting their syntax when I first learned Swift.
By making them useful in two areas with largely the same semantics, it helps you understand and use them in practice more.
In the end it’s all fairly subjective, but it doesn’t bother me as a relative newcomer.
The proposal doesn't seem to have one.
https://github.com/apple/swift-evolution/blob/master/proposa...
(The last example in your link shows using a keypath to specify a sort criteria. That's a nice use of keypaths, but isn't helped by this new feature.)
This was the exact motivation. It was part of a refactoring to clean up some implementation details and resulted in a net deletion of lines of code.
IMO, some better alternatives, in order of personal preference:
* Give away the functionality to all types that implement only a single function.
* Require an explicit protocol conformance. I get that the language does not want features to be hidden away, but requiring a user to implement a function with a specific name and signature is literally the job of a protocol. It doesn't seem like much of a hurdle for non-beginners, who have likely been familiarized with core protocols like Sequence or Collection, to acquire a knowledge of a CallAsFunction protocol.
* Introduce a new keyword, or tag (like @implicit).
* Allow the user to unlock the functionality through a more obscure phrasing. Even something as ugly as "func ` `()" could be preferable.
> Xcode 11.4 requires a Mac running macOS Catalina
Shit.
But you're not allowed to submit apps to the stores with unofficial toolchains.
IIRC, the toolchain checks the versions of SDKs shipped in the installed Xcode and refuse to compile your source code if anything's not up to date.
> But you're not allowed to submit apps to the stores with unofficial toolchains.
Not sure this is true. Apple does not allow you to copy/run Xcode from non-Apple hardware. Other than that, submitting an app built with an OSS toolchain should be fine.
https://developer.apple.com/library/archive/documentation/To...
Subscript default arguments will also be really useful.
Not sure about the callAsFunction() stuff, but I'm sure people will come up with good ideas for it.
That being said, releases like this are pretty frustrating because they seem to reflect a focusing on tiny bits of sugar (can we even call them that?) instead of features that have a much more positive influence experience. Besides "better error messages" how do any of these things improve the development experience?
`map(\.name) vs map { $0.name }`. Why...?
`callAsFunction()` feels bizarre... how is `obj()` more elegant or less confusing than `obj.callAsFunction()`.
Meanwhile the Swift dev experience still has lots of annoying bugs & usability issues (though to its credit it has improved by leaps about bounds). My personal pet peeve is that sensible compiler synthesized inits[1] still have not been implemented despite requests (and proposals!) coming up again[2] and again[3] and again[4] and again[5]
Sometimes I wonder if anyone is actually asking questions like "what value is this providing to the user?". Maybe there's so many strong opinions nothing of substance can get through the approval process?
Announcements like this[6] get me excited that the language is heading in the right direction, but it'll be a lot more convincing when the a release shows that.
[1] https://github.com/apple/swift-evolution/blob/master/proposa...
[2] https://forums.swift.org/t/it-should-be-possible-to-generate...
[3] https://forums.swift.org/t/explicit-memberwise-initializers/...
[4] https://forums.swift.org/t/default-struct-initializer-intern...
[5] https://stackoverflow.com/questions/26224693/how-can-i-make-...
This article is about changes to the language. The bulk of the effort in this release went into improving the _compiler_: better error messages, faster compile times, smaller code size, and fixing bugs.
> And this will return all users who have a best friend:
should be
> And this will return all best friends of users:
`let bestFriends = users.compactMap(\.bestFriend)`
Add to it constant major releases requiring new xcode or MacOs. Suddenly all your existing App codes have to be upgraded to even release to appstore. I swear justice will one day be served Apple for abusing the high end smartphone monopoly.