Les opérateurs «++» et «-» ont été désapprouvés Xcode 7.3


139

Je regarde les notes de Xcode 7.3 et je remarque ce problème.

Les opérateurs ++ et - sont obsolètes

Quelqu'un pourrait-il expliquer pourquoi il est obsolète? Et ai-je raison de dire que dans la nouvelle version de Xcode, vous allez maintenant utiliser à la place de ++ceci x += 1;

Exemple:

for var index = 0; index < 3; index += 1 {
    print("index is \(index)")
}

Capture d'écran d'avertissement


6
Je pense que cette question sort du cadre de stackoverflow principalement parce que toute la proposition acceptée pour l'évolution rapide peut être trouvée dans Github, vous pouvez en savoir plus sur le pourquoi de cette proposition github.com/apple/swift-evolution/blob/master / propositions /…
Victor Sigler

7
J'envisage sérieusement de revenir à Objective-C. Cela ne vaut pas la peine d'essayer de suivre tous les changements apportés à Swift.
Greg Brown

3
@OlegGordiichuk C'est la chose que les boucles for comme le style C seraient également supprimées, voir ce github.com/Vkt0r/swift-evolution/blob/master/proposals/… donc vous n'avez pas besoin d'utiliser plus d' opérateurs ++et--
Victor Sigler

10
Il y a trop de changements de rupture à mon goût. Je suis tout à fait pour les améliorations, mais je ne veux pas vraiment passer mon temps à réécrire des portions substantielles de ma base de code à chaque fois qu'une version ponctuelle de Xcode sort.
Greg Brown

4
@Fogmeister Je ne sais pas comment je pourrais être plus clair. Je préfère utiliser Swift, mais je ne pense pas qu'il soit suffisamment stable. J'ai beaucoup travaillé avec d'autres langues dans le passé et je n'ai jamais rencontré autant de changements de rupture en si peu de temps. J'ai l'impression qu'Apple veut que nous adoptions tous Swift, mais ils rendent la tâche plus difficile qu'elle ne devrait l'être.
Greg Brown

Réponses:


210

Une explication complète ici de Chris Lattner, le créateur de Swift. Je vais résumer les points:

  1. C'est une autre fonction que vous devez apprendre tout en apprenant Swift
  2. Pas beaucoup plus court que x += 1
  3. Swift n'est pas C. Ne devrait pas les reporter juste pour plaire aux programmeurs C
  4. Son utilisation principale est dans la boucle for de style C:, for i = 0; i < n; i++ { ... }Swift a de meilleures alternatives, comme for i in 0..<n { ... }(la boucle for de style C sort également )
  5. Peut être difficile à lire et à maintenir, par exemple quelle est la valeur de x - ++xou foo(++x, x++)?
  6. Chris Lattner n'aime pas ça.

Pour ceux qui sont intéressés (et pour éviter la pourriture des liens), les raisons de Lattner dans ses propres mots sont:

  1. Ces opérateurs augmentent la charge d'apprendre Swift en tant que premier langage de programmation - ou tout autre cas où vous ne connaissez pas déjà ces opérateurs dans une langue différente.

  2. Leur avantage expressif est minime - x ++ n'est pas beaucoup plus court que x + = 1.

  3. Swift s'écarte déjà de C en ce que =, + = et d'autres opérations de type affectation retournent Void (pour un certain nombre de raisons). Ces opérateurs sont incompatibles avec ce modèle.

  4. Swift a des fonctionnalités puissantes qui éliminent la plupart des raisons courantes pour lesquelles vous utiliseriez ++ i dans une boucle for de style C dans d'autres langages, donc celles-ci sont relativement rarement utilisées dans du code Swift bien écrit. Ces fonctionnalités incluent la boucle for-in, les plages, l'énumération, la carte, etc.

  5. Le code qui utilise réellement la valeur de résultat de ces opérateurs est souvent déroutant et subtil pour un lecteur / mainteneur de code. Ils encouragent le code "trop ​​délicat" qui peut être mignon, mais difficile à comprendre.

  6. Bien que Swift ait un ordre d'évaluation bien défini, tout code qui en dépendait (comme foo (++ a, a ++)) ne serait pas souhaitable même s'il était bien défini.

  7. Ces opérateurs sont applicables à relativement peu de types: scalaires entiers et à virgule flottante, et concepts de type itérateur. Ils ne s'appliquent pas aux nombres complexes, aux matrices, etc.

Enfin, ceux-ci échouent à la métrique "si nous ne les avions pas déjà, les ajouterions-nous à Swift 3?"


54
Je pense que la vraie réponse est le numéro 6. C'est OK, nous (anciens programmeurs C, Java, ...) sommes assez flexibles :-). Généralement, pour le monde réel, la mutation, le croisement et la sélection suffisent. Moi, vous et Cris aussi, nous sommes tous les résultats de ces trois opérateurs ...
user3441734

5
Point 5: Celles-ci étaient toujours dépendantes de l'implémentation en C, et personne ne les a jamais faites. Définissez simplement le comportement et nous nous y habituerons. Mieux que d'avoir à revenir en arrière et à changer un vieux code parfaitement bon sans vraie raison.
Echelon le

3
J'aime le point 3. Vous ne pouvez pas être enchaîné au contrat d'héritage pour toujours. J'adore C mais vous créez un nouveau langage de programmation; Il est logique de commencer avec l'ardoise aussi propre que vous en avez besoin.
Nicolas Miari

8
C'est parce qu'Apple aime vous forcer à penser comme eux. Je pense que c'est parfaitement bien et utilisé partout où vous devez incrémenter ou décrémenter une variable. Ce n'est pas quelque chose que vous «devez apprendre», vous vous en sortirez très bien. Et le n ° 5 est juste un code mal écrit, comme je n'en ai jamais vu. Donc # 6 ça l'est. Le déprécier suffit pour me faire gratter la tête et faire une recherche sur google, alors merci de perdre mon temps Chris.
csga5000

4
@ csga5000 C'est un argument assez faible étant donné que vous pouvez simplement définir l'opérateur vous-même si vous le souhaitez vraiment. Cela n'a rien à voir avec Apple qui veut que les gens pensent comme eux. Cela ne correspond tout simplement pas à la langue. Si l ' ++n'existait pas dans les langages de style C, personne de sensé ne se pencherait sur la conception de Swift 3.0 et ne penserait qu'un ++opérateur y serait un bon ajout.
overactor le

37

Je me rends compte que ce commentaire ne répond pas à la question, mais il peut y avoir des gens à la recherche d'une solution pour faire fonctionner ces opérateurs et une telle solution peut être trouvée en bas. 😇

Je préfère personnellement ++et les --opérateurs. Je ne peux pas être d'accord avec l'opinion selon laquelle ils sont délicats ou difficiles à gérer. Une fois que le développeur a compris ce que font ces opérateurs (et que nous parlons de choses assez simples), le code doit être très clair.

Dans l'explication des raisons pour lesquelles les opérateurs étaient obsolètes, il est mentionné que leur utilisation principale était dans le style C pour les boucles. Je ne sais pas pour les autres mais personnellement , je ne pas utiliser des boucles de style C du tout et il y a encore beaucoup d' autres endroits ou des situations où ++ou l' --opérateur est utile.

Je voudrais également mentionner que varName++renvoie une valeur afin qu'elle puisse être utilisée dans le returnconsidérant varName += 1ne peut pas.

Pour tous ceux qui souhaitent continuer à travailler avec ces opérateurs, voici la solution:

prefix operator ++ {}
postfix operator ++ {}

prefix operator -- {}
postfix operator -- {}


// Increment
prefix func ++(inout x: Int) -> Int {
    x += 1
    return x
}

postfix func ++(inout x: Int) -> Int {
    x += 1
    return (x - 1)
}

prefix func ++(inout x: UInt) -> UInt {
    x += 1
    return x
}

postfix func ++(inout x: UInt) -> UInt {
    x += 1
    return (x - 1)
}

prefix func ++(inout x: Int8) -> Int8 {
    x += 1
    return x
}

postfix func ++(inout x: Int8) -> Int8 {
    x += 1
    return (x - 1)
}

prefix func ++(inout x: UInt8) -> UInt8 {
    x += 1
    return x
}

postfix func ++(inout x: UInt8) -> UInt8 {
    x += 1
    return (x - 1)
}
prefix func ++(inout x: Int16) -> Int16 {
    x += 1
    return x
}

postfix func ++(inout x: Int16) -> Int16 {
    x += 1
    return (x - 1)
}

prefix func ++(inout x: UInt16) -> UInt16 {
    x += 1
    return x
}

postfix func ++(inout x: UInt16) -> UInt16 {
    x += 1
    return (x - 1)
}

prefix func ++(inout x: Int32) -> Int32 {
    x += 1
    return x
}

postfix func ++(inout x: Int32) -> Int32 {
    x += 1
    return (x - 1)
}

prefix func ++(inout x: UInt32) -> UInt32 {
    x += 1
    return x
}

postfix func ++(inout x: UInt32) -> UInt32 {
    x += 1
    return (x - 1)
}

prefix func ++(inout x: Int64) -> Int64 {
    x += 1
    return x
}

postfix func ++(inout x: Int64) -> Int64 {
    x += 1
    return (x - 1)
}

prefix func ++(inout x: UInt64) -> UInt64 {
    x += 1
    return x
}

postfix func ++(inout x: UInt64) -> UInt64 {
    x += 1
    return (x - 1)
}

prefix func ++(inout x: Double) -> Double {
    x += 1
    return x
}

postfix func ++(inout x: Double) -> Double {
    x += 1
    return (x - 1)
}

prefix func ++(inout x: Float) -> Float {
    x += 1
    return x
}

postfix func ++(inout x: Float) -> Float {
    x += 1
    return (x - 1)
}

prefix func ++(inout x: Float80) -> Float80 {
    x += 1
    return x
}

postfix func ++(inout x: Float80) -> Float80 {
    x += 1
    return (x - 1)
}

prefix func ++<T : _Incrementable>(inout i: T) -> T {
    i = i.successor()
    return i
}

postfix func ++<T : _Incrementable>(inout i: T) -> T {
    let y = i
    i = i.successor()
    return y
}

// Decrement
prefix func --(inout x: Int) -> Int {
    x -= 1
    return x
}

postfix func --(inout x: Int) -> Int {
    x -= 1
    return (x + 1)
}

prefix func --(inout x: UInt) -> UInt {
    x -= 1
    return x
}

postfix func --(inout x: UInt) -> UInt {
    x -= 1
    return (x + 1)
}

prefix func --(inout x: Int8) -> Int8 {
    x -= 1
    return x
}

postfix func --(inout x: Int8) -> Int8 {
    x -= 1
    return (x + 1)
}

prefix func --(inout x: UInt8) -> UInt8 {
    x -= 1
    return x
}

postfix func --(inout x: UInt8) -> UInt8 {
    x -= 1
    return (x + 1)
}
prefix func --(inout x: Int16) -> Int16 {
    x -= 1
    return x
}

postfix func --(inout x: Int16) -> Int16 {
    x -= 1
    return (x + 1)
}

prefix func --(inout x: UInt16) -> UInt16 {
    x -= 1
    return x
}

postfix func --(inout x: UInt16) -> UInt16 {
    x -= 1
    return (x + 1)
}

prefix func --(inout x: Int32) -> Int32 {
    x -= 1
    return x
}

postfix func --(inout x: Int32) -> Int32 {
    x -= 1
    return (x + 1)
}

prefix func --(inout x: UInt32) -> UInt32 {
    x -= 1
    return x
}

postfix func --(inout x: UInt32) -> UInt32 {
    x -= 1
    return (x + 1)
}

prefix func --(inout x: Int64) -> Int64 {
    x -= 1
    return x
}

postfix func --(inout x: Int64) -> Int64 {
    x -= 1
    return (x + 1)
}

prefix func --(inout x: UInt64) -> UInt64 {
    x -= 1
    return x
}

postfix func --(inout x: UInt64) -> UInt64 {
    x -= 1
    return (x + 1)
}

prefix func --(inout x: Double) -> Double {
    x -= 1
    return x
}

postfix func --(inout x: Double) -> Double {
    x -= 1
    return (x + 1)
}

prefix func --(inout x: Float) -> Float {
    x -= 1
    return x
}

postfix func --(inout x: Float) -> Float {
    x -= 1
    return (x + 1)
}

prefix func --(inout x: Float80) -> Float80 {
    x -= 1
    return x
}

postfix func --(inout x: Float80) -> Float80 {
    x -= 1
    return (x + 1)
}

prefix func --<T : BidirectionalIndexType>(inout i: T) -> T {
    i = i.predecessor()
    return i
}

postfix func --<T : BidirectionalIndexType>(inout i: T) -> T {
    let y = i
    i = i.predecessor()
    return y
}

Je n'aime pas votre return (x - 1)pour les opérateurs postfix - à mon humble avis, il est plus propre de maintenir la sémantique qu'ils renvoient (une copie de) la valeur d'origine plutôt que ce que vous obtenez si vous le faitesx + 1 - 1
Alnitak

Je n'aime pas ça non plus mais je ne connais aucune autre façon (meilleure et plus propre) de faire cela. Je ne comprends pas entièrement votre deuxième point.
0101

1
Je vois, je ne voulais pas faire ça juste pour créer une autre variable (ou plutôt constante dans ce cas). Si nous ne parlons Intque de cela, le résultat de (x + 1)sera dépassé, ce qui interrompra l'exécution et ne result - 1sera donc même pas exécuté. D'autres types de données, comme Doublepar exemple, se comportent différemment, je dois donc étudier cela.
0101

3
Vous pouvez également l'utiliser deferpour cela. defer { x += 1 }; return x
Tim Vermeulen

4
pourquoi ne pas utiliser des génériques et écrire ceci en quelques lignes?
μολὼν.λαβέ

22

Apple a supprimé ++et simplifié les choses avec une autre méthode traditionnelle.

Au lieu de ++, vous devez écrire +=.

Exemple:

var x = 1

//Increment
x += 1 //Means x = x + 1 

De même pour l'opérateur de décrémentation --, vous devez écrire-=

Exemple:

var x = 1

//Decrement
x -= 1 //Means x = x - 1

Pour les forboucles:

Exemple d'incrément:

Au lieu de

for var index = 0; index < 3; index ++ {
    print("index is \(index)")
}

Tu peux écrire:

//Example 1
for index in 0..<3 {
    print("index is \(index)")
}

//Example 2
for index in 0..<someArray.count {
    print("index is \(index)")
}

//Example 3
for index in 0...(someArray.count - 1) {
    print("index is \(index)")
}

Exemple de décrémentation:

for var index = 3; index >= 0; --index {
   print(index)
}

Tu peux écrire:

for index in 3.stride(to: 1, by: -1) {
   print(index)
}
//prints 3, 2

for index in 3.stride(through: 1, by: -1) {
   print(index)
}
//prints 3, 2, 1

for index in (0 ..< 3).reverse() {
   print(index)
}

for index in (0 ... 3).reverse() {
   print(index)
}

J'espère que cela t'aides!


Ils n'ont rien remplacé; +=était là depuis le début.
Nicolas Miari

@NicolasMiari Ouais, juste éditer avec le bien meilleur format
Sohil R. Memon

@NicolasMiari Pouvez-vous vérifier maintenant?
Sohil R. Memon

3
Et ++iet --i?
Zigii Wong

7

Chris Lattner est entré en guerre contre ++ et -. Il écrit: «Le code qui utilise réellement la valeur de résultat de ces opérateurs est souvent déroutant et subtil pour un lecteur / mainteneur de code. Ils encouragent un code "trop ​​délicat" qui peut être mignon, mais difficile à comprendre ... Bien que Swift ait un ordre d'évaluation bien défini, tout code qui en dépendait (comme foo (++ a, a ++)) serait indésirable même s'il était bien défini… ceux-ci échouent à la métrique «si nous ne les avions pas déjà, les ajouterions-nous à Swift 3?» »

Apple voulait garder rapidement un langage clair, clair, non déroutant et direct. Et donc ils ont déprécié ++ et - mot-clé.


9
Nettoyer? Regardez cet enfer de rappel et appelez-le propre? Je ne suis pas d'accord ... Et j'ajouterais: laissez le ++ & - tranquille
mcatach

22
quelque chose comme ...for i in 0.stride(to: 10, by: 2)...ou ...for i in (1...10).reverse()...est propre?!
mad_manny

6
Je suis d'accord. L'argument «propre» est fondamentalement contradictoire avec le reste de Swift. Venant d'Objective-C, qui est objectivement impur, il est assez difficile d'accepter le terme «propre» comme objectif du langage Apple.
Adrian Bartholomew

2
Essayez d'analyser json et swift et dites-moi à quel point il est propre.
nickthedude

6

Capture d'écran d'avertissement

Le Fix-it featurede Xcode donne une réponse claire à cela.

Solution à l'avertissement

Remplacer ++ increment operatorpar d'anciens value += 1(opérateur à main courte) et -- decrement operatorparvalue -= 1


6

Pour Swift 4, vous pouvez restaurer les opérateurs ++et en --tant qu'extensions pour Intet d'autres types. Voici un exemple:

extension Int{
   static prefix func ++(x: inout Int) -> Int {
        x += 1
        return x
    }

    static postfix func ++(x: inout  Int) -> Int {
        defer {x += 1}
        return x
    }

    static prefix func --(x: inout Int) -> Int {
        x -= 1
        return x
    }

    static postfix func --(x: inout Int) -> Int {
        defer {x -= 1}
        return x
    }
}

Il fonctionne de la même manière pour les autres types, tels que UIInt, Int8, Float, Double, etc.

Vous pouvez coller ces extensions dans un seul fichier dans votre répertoire racine, et elles seront disponibles pour une utilisation dans tous vos autres fichiers.

J'ai remarqué quelques votes négatifs pour ma réponse ici, presque dès que je l'ai publiée. Ce que je prends comme un désaccord philosophique, plutôt que comme une critique du fonctionnement de mon code. Cela fonctionne parfaitement, si vous le regardez dans une aire de jeux.

La raison pour laquelle j'ai publié cette réponse est que je ne suis pas d'accord pour rendre les langages de programmation informatique inutilement différents les uns des autres.

Le fait d'avoir beaucoup de similitudes entre les langues les rend plus faciles à apprendre et à passer d'une langue à une autre.

Les développeurs utilisent normalement plusieurs langages de programmation, plutôt qu'un seul. Et c'est un vrai problème de passer d'une langue à une autre, quand il n'y a pas de conventions ni de standardisation commune entre les langues.

Je pense qu'il ne devrait y avoir de différences de syntaxe entre les langues que dans la mesure où cela est nécessaire, et pas plus que cela.


J'adore quand les langues «osent» être différentes. Il y a honnêtement trop de langages 'C-syntaxe', et C a été conçu il y a LONGTEMPS .. il y a eu plus de 50 ans d'expérience langagière .. peu importe, comme cette réponse n'est pas allée dans une tirade sur les opérateurs, quand même un vote favorable.
user2864740

5

Voici une version générique d'une partie du code publié jusqu'à présent. Je voudrais exprimer les mêmes préoccupations que les autres: il est préférable de ne pas les utiliser dans Swift. Je conviens que cela pourrait être déroutant pour ceux qui liront votre code à l'avenir.

prefix operator ++
prefix operator --
prefix func ++<T: Numeric> (_ val: inout T) -> T {
    val += 1
    return val
}

prefix func --<T: Numeric> (_ val: inout T) -> T {
    val -= 1
    return val
}

postfix operator ++
postfix operator --
postfix func ++<T: Numeric> (_ val: inout T) -> T {
    defer { val += 1 }
    return val
}

postfix func --<T: Numeric> (_ val: inout T) -> T {
    defer { val -= 1 }
    return val
}

Cela peut également être écrit comme une extension sur le type numérique.


J'ai ajouté @discardableResultà chacune de ces fonctions pour faire taire l'avertissement concernant la valeur de retour étant inutilisée; sinon exactement ce que je cherchais.
Devin Lane

4

À partir de la documentation :

Les opérateurs d'incrémentation / décrémentation de Swift ont été ajoutés très tôt dans le développement de Swift, en tant que report de C. Ils ont été ajoutés sans trop de considération, et n'ont pas été beaucoup réfléchis depuis. Ce document fournit un nouveau regard sur eux et recommande en fin de compte de les supprimer complètement, car ils sont déroutants et ne portent pas leur poids.


En d'autres termes, cette opération est trop coûteuse pour être utilisée?
Oleg Gordiichuk

2
github.com/apple/swift-evolution/blob/master/proposals/ ... ici, vous pouvez lire à ce sujet, mais ce n'est pas parce que c'est cher, mais plutôt la conception du langage.
Dániel Nagy le

Alors que i Andersen Swift va abandonner le support des fonctionnalités de style C
Oleg Gordiichuk

2
@OlegGordiichuk eh bien, je dirais qu'ils veulent souligner que Swift n'est pas un sur-ensemble de C contrairement à Objective-C.
Dániel Nagy le

1
@mah beaucoup de ce que vous avez dit n'a tout simplement aucun sens. "Pas orienté vers les développeurs existants" de quelle manière? De la même manière que Java n'est pas orienté vers les développeurs PHP? "orienté vers ceux qui n'ont peut-être pas l'envie d'être des développeurs"? Ouais, parce que tous ces non-développeurs se mordent la main avec la programmation orientée protocole et les génériques. "Un moyen de permettre un bon design" jetez un œil à SO, vous verrez qu'aucun langage de programmation ne peut "permettre un bon design".
Fogmeister le

0
var value : Int = 1

func theOldElegantWay() -> Int{
return value++
}

func theNewFashionWay() -> Int{
let temp = value
value += 1
return temp
}

C'est définitivement un inconvénient, non?


5
Vous voulez dire élégant comme dans "il faut se souvenir de toutes les subtilités du langage de programmation C, sinon il n'est pas immédiatement évident si le premier appel renvoie 1 ou 2"? Je pense que nous pouvons tous épargner quelques lignes de code supplémentaires en échange de ne pas passer plusieurs minutes à nous gratter la tête à essayer de trouver un bug causé par une erreur stupide ...
Nicolas Miari

0

Comme vous ne travaillez jamais vraiment avec des pointeurs dans Swift, il est plutôt logique de supprimer les opérateurs ++et --à mon avis. Cependant, si vous ne pouvez pas vivre sans, vous pouvez ajouter ces déclarations d'opérateur Swift 5+ à votre projet:

@discardableResult
public prefix func ++<T: Numeric>(i: inout T) -> T {
    i += 1
    return i
}

@discardableResult
public postfix func ++<T: Numeric>(i: inout T) -> T {
    defer { i += 1 }
    return i
}

@discardableResult
public prefix func --<T: Numeric>(i: inout T) -> T {
    i -= 1
    return i
}

@discardableResult
public postfix func --<T: Numeric>(i: inout T) -> T {
    defer { i -= 1 }
    return i
}

-3

Dans Swift 4.1, cela pourrait être réalisé de cette manière:



    prefix operator ++
    postfix operator ++
    extension Int{
        static prefix func ++(x: inout Int)->Int{
            x += 1
            return x
        }
        static postfix func ++(x: inout Int)->Int{
            x += 1
            return x-1
        }
    }
    //example:
    var t = 5
    var s = t++
    print("\(t) \(s)")


Notez que malgré le fait que cette solution est similaire aux solutions précédentes de cet article, elles ne fonctionnent plus dans Swift 4.1 et cet exemple fonctionne. Notez également que quiconque ci-dessus mentionne que + = est un remplacement de ++ ne comprend tout simplement pas pleinement l'opérateur car ++ combiné à une affectation est en fait deux opérations, d'où un raccourci. Dans mon exemple:var s = t++fait deux choses: attribuer la valeur de t à s puis incrémenter t. Si le ++ vient avant, ce sont les deux mêmes opérations effectuées dans l'ordre inverse. À mon avis, le raisonnement d'Apple sur les raisons de supprimer cet opérateur (mentionné dans les réponses précédentes) n'est pas seulement un faux raisonnement, mais en outre, je pense que c'est un mensonge et la vraie raison est qu'ils n'ont pas pu obliger leur compilateur à le gérer. Cela leur a posé des problèmes dans les versions précédentes, alors ils ont abandonné. La logique de «l'opérateur trop compliqué à comprendre, donc supprimé» est évidemment un mensonge car Swift contient des opérateurs bien plus compliqués et beaucoup moins utiles qui n'ont pas été supprimés. En outre, la grande majorité des langages de programmation l'a. JavaScript, C, C #, Java, C ++ et bien d'autres. Les programmeurs l'utilisent avec plaisir. Pour qui il est trop difficile de comprendre cet opérateur,

La stratégie derrière Swift est simple: Apple pense que le programmeur est stupide et doit donc être traité en conséquence.

La vérité est que Swift, lancé en septembre 2014, était censé être ailleurs maintenant. D'autres langues ont grandi beaucoup plus vite.

Je peux énumérer de nombreuses erreurs majeures dans le langage, des plus sérieuses: comme les tableaux collés par valeur et non par référence, aux ennuyeuses: les fonctions de paramètres variadiques ne peuvent pas accepter un tableau qui est l'idée même derrière. Je ne pense pas que les employés d'Apple soient même autorisés à regarder d'autres langages tels que Java, donc ils ne savent même pas qu'Apple est à des années-lumière. Apple aurait pu adopter Java comme langage mais de nos jours, le défi n'est pas la technologie, mais l'ego l'est. S'ils avaient ouvert IntelliJ pour écrire un peu de Java, ils fermeraient à coup sûr leur entreprise en sachant qu'à ce stade, ils ne peuvent et ne rattraperont jamais.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.