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

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?

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.

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.

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)

You have to use _ to make your parameters unnamed, and that is unfortunate. Instead of tacking _ on to each parameter and then blindly calling your function I would suggest making a wrapper object.

Since losing named parameters for function types introduces more risk that you will call the function with the wrong values, I would suggest wrapping the parameters in a struct and having that be the one and only parameter to your function.

This way the fields of you struct are named, and there is only one type of value to pass into your function. It is more cumbersome than if we were able to name the parameters of the function, but we can't. At least this way you'll be safer and you'll feel less dirty.

struct LineNoteCellState {

    var lineNoteText: String?
    var printOnInvoice = false
    var printOnLabel = false
}

Here is an example of it being used:

cell.configure(editCallback: { (_ state: LineNoteCellState) in
            
    self.lineNoteText = state.lineNoteText
    self.printOnInvoice = state.printOnInvoice
    self.printOnLabel = state.printOnLabel
})

Semi-workaround, note the _

completion: (_ success: Bool) -> Void