But it you do that, then you'll have to write { timer in ... } when defining a closure, no?

Yes, we will have to write that, or { _ in ... }
It's mainly for the sake of NSTimer.every(#time#) { ... } because most of the time we don't have to create a var or let for it.
We can write invalidate condition inside the closure.

With NSTimer.after..., we can keep the old way.

Maybe we can overload every with a second variant that doesn't take any arguments in its closure? Can you check if it's possible to make the timer argument optional in some way?

Theorically, yes. But I'm afraid of the error ambiguous use of ...
For example (this one from ExSwift):
each (call: (Element) -> ())
each (call: (Int, Element) -> ())

Sometimes I cannot use it likes each { item in ... } or each { $0.doSth() }
I have to write it this way: each { (index, item) in ... } oreach { (_, item) in ... } `
Swift thinks these methods are ambiguous, I don't know why though.

I'll give it a try.

Thanks, hopefully Swift can handle this case :)

ambiguous use of 'after'...

Best I can do is:

NSTimer.after(5.0.seconds) { // it works
       log("abc")
}

NSTimer.after(5.0.seconds) { (timer: NSTimer!) -> Void in // this one works too
        log("abc")
}

NSTimer.after(5.0.seconds) { timer in // ambiguous
        log("abc")
}

I have to doubled every function in souce code file, and it looks ugly because Objective-C doesn't handle function overload as well as swift.

Done on master.