78 votes

Xcode 8: les types de fonction ne peuvent pas avoir d'étiquette d'argument brisant ma construction

Il semble que, pour une raison quelconque Swift ont choisi de faire le codage en moins lisible en forçant les utilisateurs à supprimer gestionnaire d'achèvement des étiquettes de paramètres. J'ai lu le Swift discussion et pense toujours que c'est une erreur. Ils auraient pu au moins fait facultatif.

Lors de la construction à l'aide de Xcode 8 - est-il un moyen de forcer le compilateur à utiliser Swift 2.3 donc je ne reçois pas ces erreurs plus? J'ai mis à jour la possibilité d'utiliser l'héritage Swift (sous paramètres de construction) legacy support in xcode mais j'ai encore l'air d'obtenir cette erreur:

Des types de fonction ne peut pas avoir d'argument label "isloggedIn", utiliser '_' au lieu de cela

error Xcode 8

Comment puis-je garder mes étiquettes dans ma achèvement des gestionnaires?

106voto

Crashalot Points 3805

La Swift créateurs ont décidé d'interdire l'argument des étiquettes pour des types de fonction.

Le raisonnement est expliqué ici: https://github.com/apple/swift-evolution/blob/master/proposals/0111-remove-arg-label-type-significance.md

C'est une source de frustration et de choix discutable, en interdisant l'argument des étiquettes rend beaucoup plus facile à tort d'invoquer des fermetures, ce qui semble plus important que la simplification du système de type du langage.

L'utilisabilité > idéologie.

27voto

sjwarner Points 3137

Une solution de contournement à considérer. Tu ne peux pas faire:

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

... mais vous pouvez faire:

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

c'est-à-dire que vous avez un seul argument non nommé à votre clôture, qui est un tuple, dans ce cas (foo: Int, bar: String) .

C'est moche à sa manière, mais au moins vous conservez les étiquettes d'argument.

Avertissement: Je n'ai pas pensé aux implications de cette approche en termes de capture ou de performances.

14voto

androidbloke Points 720

Sur la base des informations ci - dessus, il apparaît que la seule façon de vraiment résoudre ce problème et s'assurer que sa performance est d'élever une proposition de Faire argument d'étiquettes en option en vue de :

  1. l'amélioration de la vitesse de développement ( sans argument labels qui nous oblige à faire défiler jusqu'en haut de la méthode à chaque fois que nous avons mis dans le gestionnaire d'achèvement.
  2. Réduire les Erreurs : ( j'ai déjà eu plusieurs erreurs dues à une mauvaise gestionnaire d'achèvement des entrées surtout avec ceux qui attendent des des valeurs booléennes)
  3. Rendre le code plus lisible à travers les membres de l'équipe. Le monde n'a pas un seul membre de l'équipe et ainsi être en mesure de facilement choisir d'autres peuples code est un must.
  4. Enfin bon, en programmation, signifie que la solution devrait ressembler un peu comme l'objet actuellement en cours d'élaboration. completionhandler: (newvalues, nil) ressemble moins à l'élément en cours de gestion que completionhandler(results: newValue, error:nil)

Je voudrais bien que les gens la lecture de ce faire part de leurs commentaires/ comments sur ce ci-dessous avant de me présenter donc je peux montrer il ya d'autres qui en charge cette.

Edit: J'ai soumis le terrain ici : https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20161010/028083.html qui semble avoir été accepté. Il ressemble à sa va se passer, cependant la discussion est de savoir si ce qui est présenté comme une Swift 4 amélioration ( très probable)

9voto

P1X3L5 Points 1778

Vous devez utiliser _ pour faire vos paramètres sans nom, et c'est dommage. Au lieu de virer de bord _ sur chaque paramètre et ensuite aveuglément l'appel de votre fonction, je voudrais suggérer de faire un wrapper de l'objet.

Depuis la perte de paramètres nommés à la fonction de types présente plus de risques que vous allez appeler la fonction avec les valeurs erronées, je vous suggère d'envelopper les paramètres dans une struct et être le seul paramètre à la fonction.

De cette façon, les champs de vous struct sont nommés, et il n'y a qu'un seul type de valeur à passer dans votre fonction. Il est plus encombrant que si nous avons été en mesure de nommer les paramètres de la fonction, mais nous ne pouvons pas. Au moins de cette façon vous serez plus en sécurité et vous vous sentirez moins sale.

struct LineNoteCellState {

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

Voici un exemple de son utilisation:

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

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

7voto

Maciej Swic Points 2010

Solution partielle, notez le _

 completion: (_ success: Bool) -> Void
 

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X