8

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 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 multiply: (Int, Int) -> Int =
{
(a: Int, b: Int) -> Int in

// do Something else

return a * b
}
Why oh why isn't this more simply and elegantly written as:

let multiply = (a: Int, b: Int) -> Int
{
// do Something else

return a * b
}
The equals sign shows clearly that it's a closure definition assignment, as does the starting 'let'. But this way all of the stupid 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.

Now I know that with the stupid ability of Swift you can reduce all this down to return $0 * $1, but the point I'm making is that a) that's not as clear and more importantly b) if this closure does something more than just one line of code, then all that complicated stuff - hinted to by the comment '// do Something else' means you can't reduce it to stupid tokens.

So, when you have a clousure that has a lot of stuff going on and you can't reduce it to stupid minimalism, then why isn't is formatted and syntactically better like the suggestion above?

I've mentioned this on the Swift.org (and got banned for criticising Swift) but the suggestions they came up with were 'use type inference' to remove the first set of params / return type and token.

But that still means the param list and return type are NOT on the same line as the declaration and you still need the stupid 'in' keyword!

Comments
  • 0
    Never worked on swift and not entirely sure about what you said, but I know closures so I get your point (I think). But I am really fascinated by the fact that the redundant 'in' keyword disturbs you and it rightfully should! Attention to such small little nuances can lead to huge improvements in the long run!
  • 1
    You could try out Haskell, it's satisfyingly terse (arguably a bit too much sometimes)
    Would make Swift even more annoying though, so there's that.
  • 1
    @RememberMe the only bad thing here is that we can't use it for ios devel :(
  • 1
    @AleCx04 I know, I know
    I saw this for Mac apps though, I wonder if it's possible to do this for iOS (probably is but setting up the toolchain and stuff would probably be a pain)
    https://github.com/nanotech/...
  • 1
    @RememberMe that actually looks really interesting!
Add Comment