ios - programacion - tipos de funciones en c

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

Question

Parece que por alguna razón Swift ha optado por hacer que la codificación sea menos legible al obligar a los usuarios a eliminar las etiquetas de parámetros del controlador de finalización. He leído la discusión de Swift y sigo pensando que es un error. Al menos podrían haberlo hecho opcional.

Al construir usando Xcode 8, ¿hay alguna forma de forzar al compilador a usar Swift 2.3 para que ya no reciba estos errores? He actualizado la opción de usar Swift heredado (en la configuración de compilación) pero sigo teniendo este error:

Los tipos de función no pueden tener la etiqueta de argumento ''isloggedIn''; use ''_'' en su lugar

¿Cómo puedo mantener mis etiquetas en mis controladores de finalización?

Answer 1

Los diseñadores de Swift decidieron prohibir las etiquetas de argumento para los tipos de función.

El razonamiento se explica aquí: https://github.com/apple/swift-evolution/blob/master/proposals/0111-remove-arg-label-type-significance.md

Esta es una opción frustrante y cuestionable, ya que prohibir las etiquetas de argumentos hace que sea mucho más fácil invocar cierres incorrectos, lo que parece más importante que simplificar el sistema de tipos del lenguaje.

Usabilidad> ideología.

Answer 2

Según la información anterior, parece que la única forma de solucionar esto realmente y asegurarse de que su rendimiento es plantear una propuesta para hacer que las etiquetas de argumento sean opcionales con el fin de:

1. mejorando la velocidad de desarrollo (sin etiquetas de argumentos, requiere que nos desplacemos hacia la parte superior del método cada vez que incluimos 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. Haga que el código sea más legible entre los miembros del equipo. No todo el mundo tiene un solo miembro del equipo y, por lo tanto, es fácil tener el código de otras personas.
4. Por último, una buena práctica de programación significa que la solución debería parecerse tanto al elemento real que se está desarrollando. completionhandler: (newvalues, nil) parece menos al elemento que se está administrando que completionhandler(results: newValue, error:nil)

Me encantaría que las personas que lean esto compartan sus comentarios / comentarios sobre esto a continuación antes de enviarlo para poder mostrar que hay otros que lo apoyan.

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

Answer 3

Semi-solución, tenga en cuenta el _

completion: (_ success: Bool) -> Void

Answer 4

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

Dado que perder 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 que ese sea el único parámetro para su función.

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

struct LineNoteCellState {
var lineNoteText: String?
var printOnInvoice = false
var printOnLabel = false
}

Aquí hay un ejemplo de su uso:

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

Answer 5

Una solución alternativa a considerar. No puedes hacer:

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

... pero puedes hacer:

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

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

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

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