Prévision et souhaits pour la WWDC 2015

Le grand pow-wow annuel de la pomme est presque arrivé. Voici ma (bien modeste) liste de choses que j’aimerais y trouver.

Prévision

  1. Un ABI stable pour Swift. Un ABI, ou Application Binary Interface, définit les conventions par lesquelles un bout de code définit dans un fichier source peut trouver et appeler un autre bout de code définit dans un autre fichier source. Lorsque Apple a introduit Swift l’an dernier, ils ont indiqué que l’ABI du langage n’était pas stable, mais qu’il le deviendrait « dans un ou deux ans ». Pour l’instant, cette instabilité fait en sorte que tous les fichiers source composant un logiciel (y compris ceux dans des librairies et frameworks tierce-partie) doivent être compilés avec une seule et même version du compilateur Swift. L’adoption d’un ABI stable aura les effets suivants :
    1. Il permettra la distribution, en forme binaire uniquement, de librairies et frameworks écrits en Swift.
    2. Par le fait même, il permettra à Apple d’écrire des frameworks de Mac OS et iOS en Swift, ce qui mènera naturellement à une éclosion de nouveaux patterns d’utilisation.
    3. Ce sera une indication supplémentaire du sérieux d’Apple vis-à-vis leur nouveau langage, incitant ainsi plus de développeurs à faire le saut.

Souhaits

Voici des choses que j’aimerais bien voir, mais pour lesquels je n’entretiens pas vraiment d’espoir.

  1. Interopérabilité entre Swift et C++. Actuellement, Swift est interopérable avec C et Objective-C. Les développeurs dont les applications ont des noyaux multi-plateforme en C++ (ex Microsoft et DropBox) sont laissés pour compte. J’avoue que ce n’est pas nécessairement dans l’intérêt d’Apple de faciliter ce genre de développement — ils aimeraient bien mieux que les développeurs écrivent 100% de leurs applications avec les langages bénis — mais ça faciliterait le développement d’applications à grande envergure, tout en démontrant encore une fois qu’Apple prend Swift au sérieux.
  2. Ajout des exceptions à Swift. Depuis l’introduction des « failable initializer« , je pense que mon chien est mort. Il est clair que Chris Lattner et cie n’aiment pas les exceptions. Ou plutôt, que la réalité — que Cocoa et Cocoa Touch ne sont pas conçus pour fonctionner correctement en présence d’exceptions — a eu raison des avantages que les exceptions peuvent procurer. Pourtant, certaines classes dans Cocoa lancent des exceptions « non-fatales », que le code Swift n’a aucune façon d’attraper. Actuellement, la « solution » à ce problème est de passer par un intermédiaire écrit en Objective-C. C’est clairement inacceptable à moyen terme; il faudra une solution, à tout le moins pour le côté « attrapage ».