Swift Function Fun Facts
dduan.net
dduan.net
I'm not sure any one of these "work in progress" related issues are a reason to "hate Swift" (or at least, where Swift is going). It's more a reason to hate the current status of Swift as a project – since it will probably be a year or two before these sorts of non-critical issues bubble to the top of the Swift development team's priority list.
His point is that this is not just a "perceived problem", but a real problem that affects regular working programmers. What's more meat-and-potatoes than HTTP requests?
Compare that to pragmatism of not spending time trying to do what's not going to be needed.
You can always work around these issues after all the language is turing complete.
However, this is not about if there is a program that functionally equivalent, this is about writing code that is minimal and can be read well and can be supported easily over a longer period of time.
The worst code to support is "I don't use that but I might need it once."
Beyond that, the author's proposed API is most definitely not the best API design to use here, even if the default parameters did work in curried functions. A builder pattern would make a lot more sense. Or just do as Cocoa already does and provide a request object that can be customized before initiating the HTTP call.
For what reason? Isn't the gripe exactly with the fact that it's not implemented?
Also why are arguments required to be named in all calls after the first, but not the first?
func f(a: Int)(b: Int)(c: Int) -> Int { return a + b + c }
let v = f(2)(b: 5)(c: 5)
Stuff like this just eats at me when i use a language, especially when that language is brand new and other languages have had nice syntax for similar features for a long time.
func f(a: Int)(_ b: Int)(_ c: Int) -> Int { return a + b + c }
let v = f(2)(5)(5)
How should it be represented in the type system? There's no clear answer to that question.
The type of a function is `(Args) -> Ret`. `->` is basically an infix type constructor with two type parameters; it's basically sugar for something along the lines of `Func<(Args),Ret>` (except there's no actual type named that). The arguments list here is actually just a tuple, and functions with named arguments have an arguments list which is a tuple with named fields (since Swift supports that). Given all this, I don't see how default parameters could be crammed in. At a syntactic level, you could say something like `(a: Int = default, b: String = default) -> String`, but when you realize that the arguments list is a tuple, a "tuple with default field values" is a nonsense thing to try and construct.
Also, more generally, a function with default parameters is actually a family of functions, one for each valid combination of parameters. But a function value is a single function, not a family of functions. When you think about it like that, trying to return a function value with default parameters makes no more sense than trying to return a generic function that hasn't been instantiated with concrete type parameters (e.g. you cannot say `func foo() -> (<T>(x: T) -> T)` or anything along those lines). Function values must be a single concrete function, not a family of functions.
They aren't limitations by design. They are just things that the Swift team haven't gotten around to doing yet. Take a look at some of the messages from Apple engineers tracked by Swift in Flux [0], for example. It's full of things like:
> Optional methods in protocols are limited to @objc protocols only because we haven't implemented them in native protocols yet. This is something we plan to support.
…and:
> > [Is there any] specific reason why you can't reference initializers like a function?
> No particular reason, it's just not implemented.
…and:
> We currently have limitations in the type system and implementation that force some things (e.g. countElements and many others) to be global functions instead of methods, but we consider this a deficiency, not a feature.
…and:
> The prevalence of generic free functions is more about current language limitations than an intentional stylistic direction
It's a good language, but it's terribly unfinished. Back when Swift was in beta, things like this were to be expected, but Swift 1.2 feels more like Swift 0.2 to me. Apple are filling in the missing parts, but at the rate they are going, it will probably only end up feeling like a complete language at next year's WWDC.
It's not the only issue. I put it down to how new the language is and how many non-critical issues they can fix.
Swift 1.2 has been a massive improvement with incremental compiling and the SourceKit HUD not flickering in my face every few minutes. But still Xcode crashes frequently.
With all the known problems considered, I still find that the advantage of using Swift far outweighs the small number of issues with it in its current version.