@marc_os
la vache c'est non seulement vicieux mais ça doit pas être interdit des trucs comme ça ?

@ marc_os : « Dans un switch on a bien avec "affectation" du côté des let il n'y a pas de signe "=".
Dans cette syntaxe foireuse il tombe du ciel. »

Mais non, ça ne tombe pas du ciel. Dans un switch, il n’y a pas de = car l’expression qui fournit la valeur est donnée au niveau du mot-clef « switch ».
Vu qu’ici on n’est pas dans le cadre d’un switch et on veut fournir la valeur via une expression sur la même ligne, ça utilise le signe égal. Ce n’est pas illogique.
Ce qui me dérange le plus dans cette syntaxe, c’est que la position du « let » soit forcée à côté de la variable ; je pense que j’aurais eu plus de facilité à lire « guard let case(…) = … ».

« Sans parler du "case" sans switch. »

Le mot-clef « case » est employé pour signifier un usage de pattern-matching. Je crois qu’il n’y a pas de logique plus pousée au choix de ce mot que le fait que le premier usage du pattern-matching a été dans le switch. Du coup, ce n’est pas joli, mais ça a le mérite d’être homogène. J’aurais préfére que ce soit homogénéisé autour d’un terme plus explicite, comme « match », mais alors certains auraient râlé parce que le switch aurait utilisé « match » plutôt « case ».

« Mais bon, c'est compact. »

Ce n’est pas tellement la recherche de compacité (pas excessivement présente dans le développement de Swift, même s’il y a régulièremenet du monde venant sur Swift Evolution proposer des raccourcis syntaxiques totalement superflus) qui a mené à ça. Juste la volonté d’offir l’accès au pattern-matching ailleurs que juste dans un switch, tout en gardant la même syntaxe par souci d’homogénéité.

« Pas trouvé mieux que d'utiliser un terme avec un sens admis, ici "dans" pour un truc où il perd son sens car ce "in" ne veut en aucun cas dire "dans". »

Ben si, ça signifie bien « ces paramètres dans ce bout de code » (ou « ces paramètre en entrée de ce bout de code », selon comment on préfère traduire le truc). Rien d’extraordinaire ni d’illogique ou de perturbant.

« Le hic, c'est que Swift chamboule des paradigmes établis depuis une éternité sans raison valable. »

Lesquels ?

« contrairement à Objective-C qui est le fruit de longues années de recherche et développement de SmallTalk, créé à l'origine dans le monde universitaire et au centre de recherche de Xerox. »

Smalltalk, je crois bien qu’il a juste été conçu au PARC, pas dans une université.
Quant à Objective C, c’est une belle adaptation des principes de Smalltalk au C, mais qui n’est qu’une surcouche assez simple et légère sur le C. Ce dont on profite le plus, ce sont les bibliothèques développées durant des décennies par NeXTStep puis Apple.
Parce qu’en Objective C pur, sans respecter la logique de Cocoa ni ses conventions de nommage, on peut faire des trucs bien horribles aussi.

« J'en doute et le résultat le confirme pour moi. »

Je pense que ça n’a pas grand chose, voire rien, à voir avec ça. Mais plutôt que d’une part tu as décidé de ne pas aimer Swift, et d’autre part tu as été confronté à trop de code moche écrit par d’autres en Swift pour avoir la moindre chance de changer d’avis.
Je soupçonne que c’est en partie dû au fait que Swift, avec sa syntaxe moins originale que celle d’Objective C, attire plus de programmeurs que ce derniers et surtout les incite moins à adapter leur style pour coller à celui existant/recommandé (parce que la syntaxe plus familière leur donne plus l’impression qu’ils peuvent écrire en C comme en C++ ou Java, mais aussi parce que le langage étant neuf, il n’y avait pas toute la base d’exemples bien établie disponible en Objective C).

« Est-ce que "in" veut dire "dans" dans ce "langage" ?
Et bien non. »

Ben… si, comme on peut bien le voir dans l’exemple que tu as fourni.

« Si au moins ils avaient utilisé par exemple "usedBy". »

Ben ça aurait été la même chose. Le même sens.

« En plus, honnêtement je ne comprends pas bien ce que [weak self] vient foutre là. »

Il vient faire la même chose qu’en Objective C dans un cas similaire. Normal : c’est le même ARC à la manœuvre, avec la même façon d’éviter de créer des cycles.

@ marc_os : « Un autre truc bien alambiqué pour rien :
[…]
Pourquoi faire simple et clair quand on peut compliquer les choses ? »

En effet.
C’est une remarque que tu devrais faire au développeur qui a écrit cette horreur, puisqu’il est tout à fait idiot d’utiliser cette version compliquée au lieu de la version simple, bien plus logique.
Mais une fois de plus, tu reproches au langage l’erreur d’un développeur, comme si Swift forçait à écire ça, alors que ce n’est pas du tout le cas.

« Et le pire, c'est que je n'ai toujours pas trouvé les formes guard case ou if case dans la documentation officielle de Swift, mais uniquement sur des sites tiers. »

C’est bel et bien cité dans la documentation comme possibilité, mais ça mériterait effectivement de donner bien plus d’exemples. Et pas juste dans la section « patterns », mais aussi dans la section « control flow », histoire de savoir dès qu’on parle de if/guard/for qu’ils peuvent utiliser ça (et ainsi de donner envie d’aller lire l’autre section, qui n’attire pas forcément sinon).

« Ils redéfinissent des termes génériques couramment utilisés en informatique, comme ci-dessous avec le concept de "pattern". »

Il n’y a pas de redéfinition là. C’est bien le sens classique utilisé dans le cadre du pattern matching.

Tu as vraiment décidé que ça devait forcément être pourri, donc… c’est forcément pourri.
On est au niveau d’argumentation de l’Orangina rouge, là. 😉