What’s New in Swift 5.2(hackingwithswift.com)
hackingwithswift.com
What’s New in Swift 5.2
https://www.hackingwithswift.com/articles/212/whats-new-in-swift-5-2
140 comments
> They add way too much surface area to the language by allowing too many ways to do a given thing.
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."
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."
The concept of progressive disclosure means that you shouldn't teach this kind of stuff to beginners. Stuff like callAsFunction, dynamic member lookup, etc. are for people who are writing DSLs, providing rich libraries, etc.
Progressive disclosure does absolutely nothing for your students looking up example code only to be greeted by alien syntax that does the same thing.
Pretend you know nothing about a language, why would you assume .map { $0.thing } and .map(\.thing) are even remotely similar?
Pretend you know nothing about a language, why would you assume .map { $0.thing } and .map(\.thing) are even remotely similar?
You would look it up, as you would for anything else you see for the first time.
I wonder if there's a coding interface for beginners that works as follows:
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.
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.
Syntax duplication has a huge cognitive overhead.
Scala knows something about this and made a 180-degrees turn recently.
Swift is a lot like Scala. Swift creators, please not repeat Scala's mistakes.
Swift is a lot like Scala. Swift creators, please not repeat Scala's mistakes.
I use Scala everyday (in spark) and generally prefer it over java but I agree that the surface area is too large. This is really evident when you start to import someone else’s libraries. The breadth of the language affords many different paths for the library writer depending On how much of a language sniper they are.
We have the exact same problem with Typescript. We've solved it with an extremely judicious use of the linter, which prohibits certain constructs, certain patterns, and tries its best to get rid of weird features. The first thing I thought when I read `callAsFunction` was "sounds like a new lint rule someone has to write to disable that garbage."
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.
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.
> We've solved it with an extremely judicious use of the linter, which prohibits certain constructs, certain patterns, and tries its best to get rid of weird features.
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?
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 work at an all typescript shop and I really recommend checking out https://github.com/xojs/eslint-config-xo-typescript#readme as this is a full time open source developer that has to field all kinds of PR's from strangers. So it saves them time if the linter flags things they're trying to avoid.
I have not looked in to Typescript myself yet, but I would say that an “AirBnB style guide”-type linter ruleset could make picking it up much easier.
It shouldn't be much of a concern if you're already writing JS, which usually already comes with judicious use of the linter.
Not the OP but what system are you coming from? If JS, then TS is a great improvement. If anything else...probably not going to be a fun time.
This. I'm already adding callAsFunction to my team's linter, should be a stupid simple match since you can block declaring the capability in anything.
I regularly check the forums for Swift, and am dismayed at a lot of the discussion being interested in adding syntactic sugar over real new features. I fear that Swift will head down the route of C++ where there ends up being so many ways to do one thing that it's not reasonable to keep up with it all.
I was all prepared to disagree with you until I read the details ... and yeah, I agree.
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.
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.
How odd, I was all prepared to come in and find other folks excited about callAsFunction. It seems rather straightforward, although I will admit Swift is my daily driver.
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.
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.
You make good points, and I think I am overreacting!
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.
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.
> 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 could (and do) say the same thing about Perl.
I could (and do) say the same thing about Perl.
I don't think anyone in the Swift community wants the Perl's reputation as a write-only language, but changes like callAsFunction are how we get there.
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()
I can already imagine cases where callAsFunction() would be handy. For example, having a viewTemplate = SomeView(customization: etc) then creating copies via viewTemplate()
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.
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.
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.
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.
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.
They've had similar thing to callAsFunction in Dart for many years now (maybe the start). I've written many thousands of lines of Dart code, and I've never used it once, and I don't like it.
What amazes me as a huge Swift fan is that crap like callAsFunction gets priority over things like proper async/await.
You're surprised a relatively easy to implement, one off feature with no dependencies and no impact on the rest of the language can be done before a feature that impacts huge areas of the language and requires underlying runtime and compiler support?
It's easy enough to say things like "well if you don't like it don't use it". Meanwhile as a primarily swift dev I can't stop others (outside of my team) from using this disastrous syntax.
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.
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.
Well callAsFunction is extremely simple to implement and test. Where as async/await is a much bigger and more complex feature. It's not amazing, it's totally logical.
I understand the difference in difficulty, my point is any incremental time spent on this is wasted and could have contributed towards something else that's useful.
That's not how software development works.
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.
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.
> I'm going to find him something simpler to work on.
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?
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?
This syntax already exists in the language. If you want users to be able to use the obj() syntax you can already give them a closure for obj. Allowing it for user-defined types too removes an artificial syntactic distinction.
Async/await might actually help you clean up your codebase. Much better to have more syntactical sugar to keep code reviews lively and add more surprises for future developers!
i happen to be learning swift and, as a newcomer to the language, i have concluded that the level of complexity is pretty much on par with cpp. one thing i have noticed is that swift maintains readability while being complex. that's the surprised to me. complex cpp is simply not pleasant to read.
You can thank limiting the use of pointers and macros for that.
This is where a strong tech-lead and coding style guidelines are a must on any team. There will always be code ramp-up time for any engineer, junior or senior, even if everything was written in plain old C. So you need to adhere to what you consider readable as a team and discourage cleverness.
Or go full meta and discourage "cleverness" during the Swift Evolution process it seems.
I mostly agree with you, but also can that it can be nice whenever you have a class that has some state and only a single method. If you have this, you no longer have to pick separate names for the class and the function.
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.
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.
It was indeed; it was proposed and implemented by engineers working on the Swift For TensorFlow project. The earlier dynamic callable features were as well, in order to offer Python interop.
It's just C++'s operator(), right?
To me callAsFunction() looks like the reintroduction of currying, but the naming is pretty magical.
Sorry, but can someone explain the usecase for callAsFunction?
I have seen something similar before in Python where a class implements __call__, but I have never needed to use it.
I have seen something similar before in Python where a class implements __call__, but I have never needed to use it.
You hit the nail on the head. `callAsFunction` was introduced for Swift in order to interop with Python for the TensorFlow project.
> When I have to work with people who get creative and clever, it's awful
Isn't this more like a problem you have with the team, rather than a problem with the language itself?
Isn't this more like a problem you have with the team, rather than a problem with the language itself?
> Sounds more like a problem with the team, rather than a problem with the language.
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.
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.
What no one seems to be able to do is make a simple language and leave it alone to focus on tools and ecosystem. It always seems to be that the momentum of solving an initial problem with the language is carried into solving more problems with the language instead of tools.
I hope we can get to a point where we don't need to build tools and ecosystems around a single language. It seems there is just an explosion of domain and generic languages and I see that as a good thing. I want more tooling compatibility so that developers can pick and choose what works for them and maybe even mix them together better. Better educational tooling so we can pick them up faster, or read languages we don't understand easier. etc, etc. things like WebAssembly, LLVM/MLIR, python->jupyter notebooks give me hope.
How do you feel about Go? It's almost twice as old as Swift, but hasn't seen the same rise in complexity, imo. Tooling and ecosystem seem pretty solid as well.
The programming language Oberon by Niklaus Wirth is an exception. It has actually become slightly smaller over the years.
https://www.miasap.se/obnc/oberon-report.html
https://www.miasap.se/obnc/oberon-report.html
I think any useful language will have features that many people won’t use. Library writers, etc need different functionality, for example.
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
https://github.com/melling/SwiftCookBook
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)
https://github.com/melling/SwiftCookBook
What do you mean? It's trivial to add extensions to Array, Collection, or Sequence. You can find multiple examples of your additions online right now.
I didn’t say it was impossible. I said “add more generic functionality“
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:
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, +)
}
}
> I don’t believe you can add a generic function to the array to handle this.
What’s wrong with something like this?
What’s wrong with something like this?
extension Array {
func take(_ n: Int) -> ArraySlice<Element> {
self[0..<n]
}
}
The example you didn't cover using AdditiveArithmetic is actually covered in the docs here: https://developer.apple.com/documentation/swift/additivearit...
extension Sequence where Element: AdditiveArithmetic {
func sum() -> Element {
return reduce(.zero, +)
}
}I think you’re making my case for me. So, I’ll need a separate function for Ints, Strings, Floats... What if I have an Array of my custom Person objects?
[1,2,3].take(2)
[“a”,”b”,”c”].take(2)
[p1,p2,p3].take(2)
there are holes in Swift's generics system, but this isn't one of them. you don't need separate extensions for int, string, float etc. arrays. the parent post gave you a generic implementation that works with any type of array
Hmmm. I thought ArraySlice had different semantics. Why wouldn’t it be declared returning [Element]?
“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?
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?
Yes, it would. Returning an Array would require take to copy the data, slowing down your nice functional code.
This is because Swift is quite low-level when it comes to storage etc., so [0..<n] returns an ArraySlice.
However, this has nothing to do with generics.If you're willing to sacrifice performance, you could easily write
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])
}
}FWIW I'm with you on this. I'm still waiting for the rest of the generics manifesto to, you know, manifest: https://github.com/apple/swift/blob/master/docs/GenericsMani...
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.
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.
Eh. Improved error messages is good.
The rest look like they aren't worth complicating the language over. Consider:
And what's better... this?
Default arguments to subscript functions is probably OK. It's better if all kinds of function have the same capabilities.
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.
callAsFunction() isn't really intended to be used in a type like Dice there. It's a bad example.
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:
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.
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.
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.
There is an argument to be made against features that are more likely to cause harm than good (i.e. "footguns"), but I don't think this example of using it poorly sheds any light on whether that's the case here. You could, with roughly the same level of rigor, argue that allowing people to name variables is bad by constructing an example with variables named CONFUSING, CONFUSlNG and CONFUS1NG.
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.
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.
[deleted]
Scala has the same thing with apply() and it works great, allowing the language to have a consistant syntax for function calls, object creation, and array index access.
What's the difference between a callable object and a closure? I don't see why a language needs both.
Closures are completely unnecessary to start with yet I don’t see you bemoan their existence.
“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.
“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.
What unnecessary boilerplate is obviated by callable objects in a language that already has closures?
Having to wrap every use of whatever method in a closure when you could just pass the object itself eg
(map (fn [x] (get m x)) a-vec)
(map m a-vec)That's not a fair comparison. You don't have to wrap every use of your method in a closure any more than you have to call the constructor of your callable class on every use.
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.
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.
How are closures unnecessary?
The venerable master Qc Na was walking with his student, Anton. Hoping to prompt the master into a discussion, Anton said "Master, I have heard that objects are a very good thing - is this true?" Qc Na looked pityingly at his student and replied, "Foolish pupil - objects are merely a poor man's closures."
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...
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...
Anything you do with a closure, you can do with an object that holds the closed-over state and a function that performs the same operation on that state. For a real-world example of this in action, partial application is traditionally associated with closures, but Python's functools.partial() is implemented as a callable object that holds the partially applied function and parameters in instance variables.
> Functions are, of course, objects in Python, so that makes sense
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.
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.
To take the contrary take, I actually welcome keypaths as functions. Why?
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.
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.
> Default arguments to subscript functions is probably OK. It's better if all kinds of function have the same capabilities.
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.
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.
You can already do this
func die(lowerBound: Int, upperBound: Int) -> () -> Int {
{ (lowerBound...upperBound).randomElement()! }
}
let d6 = die(lowerBound: 1, upperBound: 6)
let roll1 = d6()
But what if you want to do something apart from rolling with a die?
Then you can create a struct Die and change die to return that. By implementing callAsFunction you keep the same interface as before so existing callers don't break.
Aha ok. This makes far more sense actually. Its a refactor tool for replacing lambdas with callable objects.
But does it really work out? Surely you can't put these new structs into the same arrays as similar lambdas, can you?
But does it really work out? Surely you can't put these new structs into the same arrays as similar lambdas, can you?
The key path snippet is not a good example. The real value of key path is nested structures.
Well, what is a good example?
The proposal doesn't seem to have one.
https://github.com/apple/swift-evolution/blob/master/proposa...
The proposal doesn't seem to have one.
https://github.com/apple/swift-evolution/blob/master/proposa...
See last example. https://medium.com/joshtastic-blog/swift-keypaths-ea5a1ec880...
I mean an example of why this new language feature -- the ability to implicitly treat a keypath as a function -- is useful.
(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.)
(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.)
> There's one more character and the conventions for whitespace are different.
Never underestimate peoples (often irrational) hatred for sigils, or even things that remind them of sigils.
Never underestimate peoples (often irrational) hatred for sigils, or even things that remind them of sigils.
Precisely.
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.
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.
I'm pretty apprehensive about this "callAsFunction()" feature. Requiring users to name things in a specific way was the kind of awful UX our customers struggled with when using our hobbled-together marketing software.
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.
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.
There is a danger of overengineering. This is a feature that will only be used in rare situations. So it doesn't really matter that it's just a magic identifier. As long as you aren't likely to use it by accident... I'm assuming they checked GitHub that nobody has named anything callAsFunction before choosing it
Apply on objects is used constantly in Scala, why would it be different in Swift?
I'm starting to feel Swift is being overly influenced by PL nerds. I hope they keep learners in mind - plenty of kids might be learning Swift as their first language.
It's been like that ever they set up the mailing list, what happened is that people with an abundance of time on their hands started drowning the swift team with shitty ideas. The swift team tried to resist but eventually the lunatics took charge of the asylum. Swift didn't start with a very elegant foundation because of all the ObjC baggage, but instead of simplifying the language as time goes on they have just kept adding crap to it.
> The first beta of Swift 5.2 just landed with Xcode 11.4 beta
> Xcode 11.4 requires a Mac running macOS Catalina
Shit.
> Xcode 11.4 requires a Mac running macOS Catalina
Shit.
So much for semver. This should be a breaking change warranting an Xcode 12 major version.
It's been pretty standard for the last several years that the ~.3/4 Xcode point release increases the minimum macOS version.
True, and I've said the same thing every time. The status quo's fucked up.
Indeed. Generally the new macOS hasn't been a flaming dumpster fire though.
A new version of the language shouldn't require a new IDE.
It doesn't, you can download toolchains from swift.org or build them yourselves and load them into your old version of Xcode.
But you're not allowed to submit apps to the stores with unofficial toolchains.
But you're not allowed to submit apps to the stores with unofficial toolchains.
> It doesn't, you can download toolchains from swift.org or build them yourselves and load them into your old version of Xcode.
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.
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.
See the note at the bottom: "Apps uploaded to iTunes Connect must be built using the default toolchain."
https://developer.apple.com/library/archive/documentation/To...
https://developer.apple.com/library/archive/documentation/To...
Really obviates the supposedly open nature of the language.
Not really. They just require certain compiler builds to ship on their app store.
I've wanted to do the keypath expressions thing for awhile. It's not a giant improvement, but it's certainly welcome.
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.
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.
What was the motivation for `callAsFunction`? It's a toy example so `Dice(...)` is clearly bad compared to `Dice.roll(...)` but what's an example where it brings clarity over the alternative?
You can read the motivation in the evolution proposal: https://github.com/apple/swift-evolution/blob/master/proposa...
The first example with polynomials could be achieved using closures already. Type erasure on closure contexts seems unfortunate and fixing that seems like a better long term solution (granted it's probably far harder to solve). Was excited to see talk of ML though :)
[deleted]
Swift on the server? Swimming against the tide? Or expressive language, ideal for writing information systems and backed by Apple with the fantastic LLVM tool chain at your disposal?
IMO Vapor (Swift) is the future. I absolutely love it for server side.
Which distro do you use on the server? And is Swift easily installable/upgradeable there?
Not the person you were asking, but I find the Swift docker images particularly easy to install/upgrade/run in parallel.
I feel like Swift is becoming more like Ruby over time. 2 of the features here (Key Path Expressions and Subscript default arguments) were recently introduced to Ruby. This isn't a bad thing, just an interesting progression.
Key path solves a real problem for me, since you can pass in a function that accepts the value to map which looks really clean, but you cannot operate on the variable unless you create a block.
I love Swift. Writing in it is awesome, the community is great, and it has traditionally been focused on a truly wonderful dev-focused experience.
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-...
[6] https://forums.swift.org/t/on-the-road-to-swift-6/32862
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-...
[6] https://forums.swift.org/t/on-the-road-to-swift-6/32862
> 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?
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.
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.
Fundamental Truth of Computing: All languages become C++ eventually.
Minor correction:
> 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)`
> 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)`
I cant stand swift. Without ios apps, would anyone even touch this crap?
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.
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.
The language itself is amazing IMO but agreed the update hell has been annoying so far.
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.