Xcode 8 :function types cannot have argument label breaking my build

Question

It seems that for some reason Swift have chosen to make coding in it less readable by forcing users to remove completion handler parameter labels. I have read the Swift discussion and still think it's a mistake. At least they could have made it optional.

When building using Xcode 8 - is there a way to force the compiler to use Swift 2.3 so I don't get these errors anymore? I have updated the option to use legacy Swift (under build settings) but I still seem to get this error:

Function types cannot have argument label 'isloggedIn'; use '_' instead

How can I keep my labels in my completion handlers?

Answer 1

The Swift designers decided to prohibit argument labels for function types.

The reasoning is explained here: https://github.com/apple/swift-evolution/blob/master/proposals/0111-remove-arg-label-type-significance.md

This is a frustrating and questionable choice, as prohibiting argument labels makes it much easier to incorrectly invoke closures, which seems more important than simplifying the language's type system.

Usability > ideology.

Answer 2

A workaround to consider. You can't do:

func doStuff(completion: (foo: Int, bar: String) -> Void) {
    ...
    completion(foo: 0, bar: "")
}

... but you can do:

func doStuff(completion: ((foo: Int, bar: String)) -> Void) {
    ...
    completion((foo: 0, bar: ""))
}

i.e. have a single unnamed argument to your closure which is a tuple, in this case (foo: Int, bar: String).

It's ugly in its own way, but at least you retain the argument labels.

Answer 3

Based on the information above - it appears that the only way to really fix this and ensure that its performant is to raise a proposal to Make argument labels optional with a view to :

1. improving the speed of development ( without argument labels it requires us to scroll up to the top of the method each time we put in the completion handler.
2. Reduce Errors : ( I have already had several errors caused due to incorrect completion handler entries especially with those that expect boolean values)
3. Make code more readable across team members. Not everyone has only one team member and thus being able to easily pick up other peoples code is a must have.
4. Lastly good programming practice means that the solution should look as much like the actual item being developed. completionhandler: (newvalues, nil) looks less like the item being managed than completionhandler(results: newValue, error:nil)

I would love for people reading this to share their feedback/ comments on this below before I submit it so I can show there are others that support this.

Edit: I have submitted the pitch here : https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20161010/028083.html which appears to have been agreed. It looks like its going to happen, however the discussion is whether this is submitted as a Swift 4 improvement ( highly probable)