Saltar al contenido

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

Posterior a de una prolongada compilación de información hemos podido solucionar esta preocupación que suelen tener ciertos los lectores. Te ofrecemos la respuesta y esperamos resultarte de gran ayuda.

Los diseñadores de Swift decidieron prohibir las etiquetas de argumentos para los tipos de funciones.

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

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

Usabilidad > ideología.

Una solución a tener en cuenta. 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 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.

Con base en la información anterior, parece que la única forma de solucionar esto realmente y garantizar su rendimiento es plantear una propuesta para hacer que las etiquetas de argumento sean opcionales con miras a:

  1. mejorando la velocidad de desarrollo (sin etiquetas de argumentos, 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 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 todos tienen un solo miembro del equipo y, por lo tanto, es imprescindible poder recoger fácilmente el código de otras personas.
  4. Por último, una buena práctica de programación significa que la solución debe parecerse mucho al elemento real que se está desarrollando. completionhandler: (newvalues, nil) se parece menos al elemento que se administra que completionhandler(results: newValue, error:nil)

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

Editar: he enviado el tono 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)

Al final de todo puedes encontrar las notas de otros programadores, tú de igual forma tienes la opción de dejar el tuyo si lo deseas.

¡Haz clic para puntuar esta entrada!
(Votos: 0 Promedio: 0)


Tags :

Utiliza Nuestro Buscador

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *