Erica Sadun

Where technology meets something or other

Swift: () -> () vs () -> Void

For those of you who have been following along, the tl;dr answer is:

() -> Void

Everyone else: The Swift Programming Language ebook refers exclusively to () -> (). APIs all use () -> Void.

I much prefer the Void typealias because it better matches return conventions in the Objective-C world.

And now, word of Apple at devforums: “FWIW, we’ve recently decided to standardize on () -> Void (generally, () for parameters and Void for return types) across all of our documentation.”

Tweet this Post

5 Comments

  • Nice. I’m liking Void as well. It’s more chars than (), but those parens quickly turn into noise when they are wrapped on more parens.

    • Thank you for being my first comment in the new system!!!! 🙂

      • By erica

  • What happened to Objective-C without the C. Void is so C. Bleh.

    • “Void is so C?” To me returning () is less clear because it implies I’m returning an empty ‘something’ but not what that ‘something’ is when the truth is it doesn’t return anything.

      Personally I kinda like the way some other languages differ between normal and void functions by not calling void functions ‘functions’ in the first place and instead calling them methods.

      The distinction is simple.
      Functions return something.
      Methods do not.

      Then in signatures you could do ‘func(Bool,String)->Int’ or ‘method(Bool,String)’. Sure they are slightly more verbose, but there is zero ambiguity, and ‘Void’ doesn’t appear anywhere.

      I could even still concede that ‘func’ is implied, letting the existing syntax ‘(Bool,String) -> Int’ remain, but I still prefer ‘method()’ over ‘() -> ()’ *or* ‘() -> Void’

    • You could even shorten ‘method(Bool,String) to just ‘meth(Bool,String)’ if we all agree not to giggle at the unintentional Walter White reference. 🙂