I'm a C++/Obj-C programmer finding it ludicrously hard to switch to Swift.
I find that the constant ability (leading to very poor programmer code) to reduce verbosity, grammar and syntax and add tokens reduces readability and nowhere is this more apparent that with closures.
I'm working through (to my shame ;) ) Ray Wenderlich's Swift course and the closure chapter has this:
PS I loathe K&R as much as I do Swift so it's all in Allman formatting for clarity.
let handler: (Int, Int) -> Int =
{
(a: Int, b: Int) -> Int in
// do Something else
return someInt
}
Why oh why isn't this more simply and elegantly written as:
let handler = (a: Int, b: Int) -> Int
{
// do Something else
return someInt
}
The equals sign shows clearly that it's a closure definition assignment, as does the starting 'let'. But this way, all of the excesses, like the 'in' keyword, the repetition of the params / return type only this time with useful labels and additional tokens are removed and it looks and reads much more like a regular function and certainly a lot more clearly.
So, when you have a closure that has a lot of stuff going on and you can't reduce it to obfuscated minimalism ($ tokens), then why isn't is formatted and syntactically better like the suggestion above?
The example in the tutorial is not taking advantage of type inference. The same closure can be written much more concisely, without relying on anonymous $ arguments.
Either
let multiply: (Int, Int) -> Int = { a, b in
// do something else
return a * b
}
or:
let multiply = { (a: Int, b: Int) -> Int in
// do something else
return a * b
}
You're not the only one who thinks Swift's closure syntax is complicated. But so also is Objective-C's. IMO I think the beauty of Swift's closure syntax is that it lets the programmer (in most cases) choose the level of explicit typing they have to provide. If you're someone who loves $, you're free to use the most terse closures. And on the other hand, if you really just cannot stand type inference for some peculiar reason, go ahead and slap types on all the things.
The closure syntax tries to serve a lot of different purposes; I tried to explain some of the historical context in a response to this thread. For your use case, Swift also supports nested named function declarations:
func multiplyByTwoAndThree(a: Int) -> (Int, Int) {
func multiply(b: Int) -> Int {
return a * b
}
return (multiply(b: 2), multiply(b: 3))
}
and these have all the powers of closuresâthey can refer to their outer context, and be passed around as function valuesâbut also allow you to use the same syntax as top-level functions and methods, use argument labels, and so on.
As for why function types don't themselves support argument labels, see SE-111 for background; it was a cleanup of the type system and language design around function types and argument labels, to make it so that argument labels are consistently always a part of declaration names like they are in Objective-C. In accepting that proposal, we left the door open to considering allowing labels to appear again as part of declarations involving closures; in the future, we could again allow var multiply: (a: Int, b: Int) -> Int as a declaration of multiply(a:b:) as a variable.
We can and will eventually improve this by allowing compound names and with some extra sugar on top it will become what you want, at least from the call side, this wonât add argument labels even if it seems that it should because you have parameter labels which are faked.
I agree, Obj-Câs implementation is horrible too, and other than callback handlers that call other methods (for clarity) I refuse to use them as they reduce code readability and clarity.
Iâve had team members bury so much functionality hidden in (reduced syntax) closures everywhere the code is obfuscated and a rats tail nest to unpack. And these guys think itâs clever or efficient... /smh
But back to this point, having the Params and return type as part of the declaration and not buried or repeated in the body of the closure is more in keeping with all other function declarations, reduces typing and massively increases clarity.
The existing implementation is horrific.
And again, Iâll repeat, the pseudo code could be boiled to one line, but my point is that the closure does more than one line and couldnât be boiled down - I didnât see the point of typing extra stuff to make the point but people arenât reading it properly.
The things you've said you want to do â define a closure in a highly-readable style, including things like parameter names â are well-suited to a local func. The anonymous-closure syntax is optimized for "minimalism" and convenience precisely because func is available as a less compact and more readable alternative.
Also, flaming is not welcome on these forums. You're free to criticize Swift's design and ask for changes, but you can do better than calling it stupid over and over again. As a moderator, I try to be very lenient with how people phrase their criticisms of the language (and/or the core team), but there have to be limits or else that kind of posting will drive everyone else away.
Since when did 'minimalism' creep in to Swift as an edict? Apple clearly still says that code should be readable over brevity, and it should read like English.
How does anyone justify the mess of Swift's ability to reduce code to symbols and tokens and claim it's readable?
How does having (at least) three different ways to define a closure help with readability over brevity?
Is this something that crept in after it went open source or was it something from Apple?
I genuinely want to know?
If all (at least) 3 ways of defining a closure are correct, why do you need 3? Why not just have the most clear (which as I've said, isn't really clear and is very poor syntactically) and limit it to one?
This isn't the 70's. Our screens are big enough to show methods of a decent size, and if a method goes over a screen of a 27" iMac, you're doing it wrong. We need fast, scan-able, readable code - not brevity for brevities sake.
Same applies to 1TBS, as Erica Sadun and many others will state - you can't scan or parse code as quickly or easily when people use 1TBS as opposed to Allman.
The days of 'saving space' and writing 'compact code' are dead. We should let the compiler optimise it far better than virtually every programmer out there, and just write code everyone can easily read.
And btw, I have read everything people have said on this thread; and the takeaway from the people that understood I wasn't talking about a closure that could be reduced to just tokens, was that the 2nd response using inference, was the closest we could get to my suggestion.
And yes, it's a little cleaner, I still don't understand why you need the params inside the closure and the IMHO silly token of 'in' - as I demonstrated in my suggestion.
I'm not saying my suggestion is perfect, but I've yet to read any response as to why it's not better than the awkward reading mess we have.
I'm here and willing to be educated, but so far, there's no reasonable argument been made for the complexity and just unpleasantness of closure syntax.
Minimalism is not an âedict.â Swift has a range of syntaxes for anonymous closures because the optimal amount of information to include in a closure is situational: very short closures benefit from not needing an explicit parameter list at all, while longer closures benefit from being able to name parameters and (occasionally) give them types.
Thereâs never a reason to write what youâve written in your first post, though, and since thatâs your only example of how terrible Swift syntax is, itâs not surprising that people keep responding to it.
Swiftâs closure syntax predates the language being open-source by several years.
In particular, since you are giving the closure a name, you should use a nested function, which completely eliminates the syntax that you find objectionable.
