Xcode 8: los tipos de función no pueden tener una etiqueta de argumento que rompa mi compilación

Una solución a considerar. No puedes hacer:

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

... pero usted puede hacer:

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

Es decir, tener un solo argumento sin nombre para su cierre que es una tupla, en este caso (foo: Int, bar: String).

Es feo a su manera, pero al menos conservas las etiquetas de los argumentos.

Descargo de responsabilidad: No he pensado en las implicaciones de captura o rendimiento de este enfoque.

Tienes que usar _ para hacer que tus parámetros no tengan nombre, y eso es desafortunado. En lugar de marcar _ en cada parámetro y luego llamar ciegamente a su función, sugeriría hacer un objeto wrapper.

Dado que perder los parámetros con nombre para los tipos de función introduce más riesgo de que llame a la función con los valores incorrectos, sugeriría envolver los parámetros en una estructura y tener que ser el único parámetro de su función.

De esta manera los campos de ti struct se nombran, y solo hay un tipo de valor para pasar a su función. Es más engorroso que si fuéramos capaces de nombrar los parámetros de la función, pero no podemos. Al menos de esta manera estarás más seguro y te sentirás menos sucio.

struct LineNoteCellState {

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

Aquí hay un ejemplo de cómo se usa:

cell.configure(editCallback: { (_ state: LineNoteCellState) in

    self.lineNoteText = state.lineNoteText
    self.printOnInvoice = state.printOnInvoice
    self.printOnLabel = state.printOnLabel
})

Basado en la información anterior-parece que la única manera de realmente arreglar esto y asegurarse de que su rendimiento es plantear una propuesta para Haga que las etiquetas de argumentos sean opcionales con el fin de:

1. mejorando la velocidad de desarrollo ( sin etiquetas de argumento, requiere que nos desplacemos hasta la parte superior del método cada vez que colocamos el controlador de finalización.
2. Reducir errores: (Ya he tenido varios errores causados debido a entradas incorrectas del controlador de finalización, especialmente con aquellos que esperan valores booleanos)
3. Haz que el código sea más legible para todos los miembros del equipo. No todo el mundo tiene un solo miembro del equipo y por lo tanto ser capaz de recoger fácilmente código de otras personas es una necesidad.
4. Por último, una buena práctica de programación significa que la solución debe parecerse tanto al elemento real que se está desarrollando. completionhandler: (newvalues, nil) se parece menos al elemento administrado que completionhandler(results: newValue, error:nil)

Me encantaría que las personas que lean esto compartan sus comentarios/ opiniones sobre esto a continuación antes de presentarlo para que pueda mostrar que hay otros que apoya esto.

Editar: He presentado el lanzamiento aquí : https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20161010/028083.html lo cual parece haber sido acordado. Parece que va a suceder, sin embargo, la discusión es si esto se presenta como una mejora rápida 4 ( muy probable)

Semi-solución, tenga en cuenta la _

completion: (_ success: Bool) -> Void