{"id":34258,"date":"2020-04-02T10:02:25","date_gmt":"2020-04-02T09:02:25","guid":{"rendered":"https:\/\/blog.jetbrains.com\/fr\/?p=619"},"modified":"2020-04-02T10:12:16","modified_gmt":"2020-04-02T09:12:16","slug":"publication-de-kotlin-1-4-m1","status":"publish","type":"post","link":"https:\/\/blog.jetbrains.com\/fr\/2020\/04\/02\/publication-de-kotlin-1-4-m1\/","title":{"rendered":"Publication de Kotlin 1.4-M1"},"content":{"rendered":"Nous avons le plaisir de vous pr\u00e9senter Kotlin 1.4-M1, la Preview de la prochaine version majeure de Kotlin.\r\n\r\nIl y a quelques mois, nous vous avions inform\u00e9 de Ce que Kotlin 1.4 allait vous r\u00e9server. \u00c0 l'approche de sa sortie officielle, nous vous proposons une version Preview pour vous permettre d'essayer certaines de ses nouveaut\u00e9s.\r\n\r\n\r\n\r\nDans cet article, nous pr\u00e9sentons les nouvelles fonctionnalit\u00e9s et principales am\u00e9liorations apport\u00e9es par la version 1.4-M1\u00a0:\r\n\r\n\tUn nouvel algorithme d'inf\u00e9rence de type plus puissant est activ\u00e9 par d\u00e9faut.\r\n\tLes contrats sont d\u00e9sormais disponibles pour les fonctions finales des membres.\r\n\tLe compilateur Kotlin\/JVM g\u00e9n\u00e8re d\u00e9sormais des annotations de type dans le bytecode pour les cibles Java 8+.\r\n\tUn nouveau backend pour Kotlin\/JS apporte des am\u00e9liorations majeures aux artefacts r\u00e9sultants.\r\n\tChangements \u00e9volutifs dans la biblioth\u00e8que standard\u00a0: ach\u00e8vement de cycles de d\u00e9pr\u00e9ciation et d\u00e9pr\u00e9ciation de certaines parties suppl\u00e9mentaires.\r\n\r\nVous trouverez la liste compl\u00e8te des modifications dans le journal des modifications. Comme toujours, nous sommes extr\u00eamement reconnaissants envers nos contributeurs externes.\r\n\r\nNous vous encourageons vivement \u00e0 tester la Preview et attendons impatiemment les commentaires que vous ajouterez dans notre outil de suivi de tickets.\r\nAlgorithme d'inf\u00e9rence de type plus puissant\r\nKotlin 1.4 utilise un nouvel algorithme d'inf\u00e9rence de type plus puissant. Vous pouviez d\u00e9j\u00e0 essayer ce nouvel algorithme avec Kotlin 1.3 en sp\u00e9cifiant une option de compilateur. Il est maintenant utilis\u00e9 par d\u00e9faut. Vous trouverez la liste compl\u00e8te des probl\u00e8mes corrig\u00e9s par le nouvel algorithme dans YouTrack. Dans cet article de blog, nous mettrons en lumi\u00e8re certaines des am\u00e9liorations les plus notables.\r\nConversion SAM pour les fonctions et interfaces Kotlin\r\nLa conversion SAM vous permet de passer une lambda lorsqu'une interface avec une \"m\u00e9thode abstraite unique\" est attendue. Auparavant, vous ne pouviez appliquer la conversion SAM que lorsque vous travailliez avec des m\u00e9thodes et des interfaces Java de Kotlin. Vous pouvez d\u00e9sormais l'utiliser aussi avec des fonctions et des interfaces Kotlin.\r\n\r\nKotlin prend d\u00e9sormais en charge la conversion SAM pour les interfaces Kotlin. Notez qu'il fonctionne diff\u00e9remment qu'en Java\u00a0: vous devez marquer explicitement les interfaces fonctionnelles. Apr\u00e8s avoir marqu\u00e9 une interface avec le mot cl\u00e9 fun, vous pouvez passer une lambda comme argument chaque fois qu'une telle interface est attendue comme param\u00e8tre\u00a0:\r\nfun interface Action {\r\n    fun run()\r\n}\r\n\r\nfun runAction(a: Action) = a.run()\r\n\r\nfun main() {\r\n    runAction {\r\n        println(\"Hello, Kotlin 1.4!\")\r\n    }\r\n}\r\n\r\nVous pouvez en apprendre davantage \u00e0 ce sujet dans cet article.\r\n\r\nKotlin prend en charge les conversions SAM pour les interfaces Java depuis le d\u00e9but, mais il y avait un cas qui n'\u00e9tait pas pris en charge, ce qui pouvait \u00eatre ennuyeux lorsque vous travailliez avec des biblioth\u00e8ques Java existantes. Si vous appeliez une m\u00e9thode Java prenant deux interfaces SAM comme param\u00e8tres, les deux arguments devaient \u00eatre des lambdas ou des objets ordinaires. Il n'\u00e9tait pas possible de passer un argument en tant que lambda et un autre en tant qu'objet. Le nouvel algorithme corrige ce probl\u00e8me et vous pouvez dans tous les cas passer une lambda au lieu d'une interface SAM, ce qui correspond au fonctionnement qui serait naturellement attendu.\r\nInf\u00e9rence automatique du type dans plus de cas d'utilisation\r\nLe nouvel algorithme d'inf\u00e9rence inf\u00e8re des types dans de nombreux cas o\u00f9 l'ancienne inf\u00e9rence vous obligeait \u00e0 les sp\u00e9cifier explicitement. Par exemple, dans l'exemple suivant, le type du param\u00e8tre lambda it inf\u00e8re correctement \u00e0 String?\u00a0:\r\n\/\/debutExemple\r\nval rulesMap: Map<String, (String?) -> Boolean> = mapOf(\r\n    \"weak\" to { it != null },\r\n    \"medium\" to { !it.isNullOrBlank() },\r\n    \"strong\" to { it != null && \"^[a-zA-Z0-9]+$\".toRegex().matches(it) }\r\n)\r\n\/\/sampleEnd\r\n\r\nfun main() {\r\n    println(rulesMap.getValue(\"weak\")(\"abc!\"))\r\n    println(rulesMap.getValue(\"strong\")(\"abc\"))\r\n    println(rulesMap.getValue(\"strong\")(\"abc!\"))\r\n}\r\n\r\nDans Kotlin 1.3, vous deviez introduire un param\u00e8tre lambda explicite ou remplacer to par un constructeur Pair avec des arguments g\u00e9n\u00e9riques explicites pour que cela fonctionne.\r\nConversions intelligentes pour la derni\u00e8re expression de la lambda\r\nDans Kotlin 1.3, la derni\u00e8re expression \u00e0 l'int\u00e9rieur de la lambda n'est pas une conversion intelligente, sauf si vous sp\u00e9cifiez le type attendu. Ainsi, dans l'exemple suivant, Kotlin 1.3 inf\u00e8re String? comme le type de la variable result\u00a0:\r\nval result = run {\r\n    var str = currentValue()\r\n    if (str == null) {\r\n        str = \"test\"\r\n    }\r\n    str \/\/ le compilateur Kotlin sait que str n'est pas null ici\r\n}\r\n\/\/ Le type de 'result' est String? dans Kotlin 1.3 et String dans Kotlin 1.4\r\n\r\nDans Kotlin 1.4, gr\u00e2ce au nouvel algorithme d'inf\u00e9rence, la derni\u00e8re expression \u00e0 l'int\u00e9rieur de la lambda b\u00e9n\u00e9ficie d'une conversion intelligente, et ce nouveau type plus pr\u00e9cis est utilis\u00e9 pour inf\u00e9rer le type obtenu pour la lambda. Ainsi, le type de la variable result devient String.\r\n\r\nDans Kotlin 1.3, vous deviez souvent ajouter des conversions explicites (soit !!, soit des conversions de type comme as String) pour que de tels cas fonctionnent. Vous n'avez plus besoin de le faire d\u00e9sormais.\r\nConversions intelligentes pour les r\u00e9f\u00e9rences appelables\r\nDans Kotlin 1.3, vous ne pouviez pas acc\u00e9der \u00e0 une r\u00e9f\u00e9rence de membre d'un type de conversion intelligente. Vous pouvez\u00a0maintenant :\r\nsealed class Animal\r\nclass Chat : Animal() {\r\n    fun miaou() {\r\n        println(\"miaou\")\r\n    }\r\n}\r\n\r\nclass Chien: Animal() {\r\n    fun wouf() {\r\n        println(\"wouf\")\r\n    }\r\n}\r\n\r\n\/\/debutExemple\r\nfun animer(animal: Animal) {\r\n    val kFunction: KFunction<*> = when (animal) {\r\n        is Chat -> animal::miaou\r\n        is Chien -> animal::wouf\r\n    }\r\n    kFunction.call()\r\n}\r\n\/\/finExemple\r\n\r\nfun main() {\r\n    animer(Chat())\r\n}\r\n\r\nVous pouvez utiliser diff\u00e9rentes r\u00e9f\u00e9rences de membre animal::miaou and animal::wouf apr\u00e8s que la variable animal a \u00e9t\u00e9 convertie intelligemment en types sp\u00e9cifiques Chat et Chien. Apr\u00e8s les v\u00e9rifications de type, vous pouvez acc\u00e9der aux r\u00e9f\u00e9rences de membre correspondant aux sous-types.\r\nMeilleure inf\u00e9rence pour les r\u00e9f\u00e9rences appelables\r\nL'utilisation de r\u00e9f\u00e9rences appelables sur des fonctions avec des valeurs d'argument par d\u00e9faut a \u00e9t\u00e9 am\u00e9lior\u00e9e. Par exemple, la r\u00e9f\u00e9rence appelable sur la fonction foo suivante peut \u00eatre interpr\u00e9t\u00e9e \u00e0 la fois comme prenant un argument Int ou comme ne prenant aucun argument\u00a0:\r\nfun foo(i: Int = 0): String = \"$i!\"\r\n\r\nfun apply1(func: () -> String): String = func()\r\nfun apply2(func: (Int) -> String): String = func(42)\r\n\r\nfun main() {\r\n    println(apply1(::foo))\r\n    println(apply2(::foo))\r\n}\r\n\r\nMeilleure inf\u00e9rence pour les propri\u00e9t\u00e9s d\u00e9l\u00e9gu\u00e9es\r\nLe type d'une propri\u00e9t\u00e9 d\u00e9l\u00e9gu\u00e9e n'a pas \u00e9t\u00e9 pris en compte lors de l'analyse de l'expression de la d\u00e9l\u00e9gu\u00e9e qui suit le mot cl\u00e9 by. Par exemple, le code suivant ne compilait pas auparavant, mais \u00e0 pr\u00e9sent le compilateur inf\u00e8re correctement les types des param\u00e8tres old et new comme String?\u00a0:\r\nimport kotlin.properties.Delegates\r\n\r\nfun main() {\r\n    var prop: String? by Delegates.observable(null) { p, old, new ->\r\n        println(\"$old \u2192 $new\")\r\n    }\r\n    prop = \"abc\"\r\n    prop = \"xyz\"\r\n}\r\n\r\nChangements du langage\r\nLa plupart des changements apport\u00e9s au langage ont d\u00e9j\u00e0 \u00e9t\u00e9 d\u00e9crits dans des articles de blog pr\u00e9c\u00e9dents\u00a0:\r\n\r\n\tConversions SAM pour les classes Kotlin\r\n\tM\u00e9lange d'arguments nomm\u00e9s et positionnels\r\n\tOptimisation des propri\u00e9t\u00e9s d\u00e9l\u00e9gu\u00e9es\r\n\tVirgules de fin\r\n\tBreak & continue inside when\r\n\tChangements pour les fonctions tail-recursive\r\n\r\nDans cet article, nous allons aborder quelques petites am\u00e9liorations concernant les contrats.\r\nPrise en charge des contrats\r\nLa syntaxe permettant de d\u00e9finir les contrats personnalis\u00e9s reste exp\u00e9rimentale, mais nous avons pris en charge quelques nouveaux cas pour lesquels les contrats pourraient \u00eatre utiles.\r\n\r\nVous pouvez d\u00e9sormais utiliser des param\u00e8tres de type g\u00e9n\u00e9rique r\u00e9ifi\u00e9s pour d\u00e9finir un contrat. Par exemple, vous pouvez impl\u00e9menter le contrat suivant pour la fonction assertIsInstance\u00a0:\r\n@OptIn(ExperimentalContracts::class)\r\ninline fun <reified T> assertIsInstance(value: Any?) {\r\n    contract {\r\n        returns() implies (value is T)\r\n    }\r\n\r\n    assertTrue(value is T)\r\n}\r\n\r\nLe param\u00e8tre de type T \u00e9tant r\u00e9ifi\u00e9, vous pouvez v\u00e9rifier son type dans le corps de la fonction. D\u00e9sormais c'est \u00e9galement possible \u00e0 l'int\u00e9rieur du contrat. Une fonction similaire avec le message d'assertion sera ajout\u00e9e \u00e0 la biblioth\u00e8que kotlin.test ult\u00e9rieurement.\r\n\r\nDe plus, vous pouvez d\u00e9sormais d\u00e9finir des contrats personnalis\u00e9s pour les membres final. La d\u00e9finition de contrats pour les fonctions membres \u00e9tait auparavant totalement interdite car la d\u00e9finition de contrats sur certains des membres de la hi\u00e9rarchie implique une hi\u00e9rarchie des contrats correspondants, et cela reste une question de conception ouverte \u00e0 la discussion. Toutefois, si une fonction membre est final et ne remplace aucune autre fonction, cela ne pose pas de probl\u00e8me de lui d\u00e9finir un contrat.\r\nModifications de la biblioth\u00e8que standard\r\nExclusion des coroutines exp\u00e9rimentales obsol\u00e8tes\r\nL'API kotlin.coroutines.experimental a \u00e9t\u00e9 remplac\u00e9e par kotlin.coroutines dans la version 1.3.0. Dans la version 1.4-M1, nous finalisons le cycle d'obsolescence de kotlin.coroutines.experimental en le supprimant de la biblioth\u00e8que standard. Pour ceux qui l'utilisent encore sur la JVM, nous fournissons un artefact de compatibilit\u00e9 kotlin-coroutines-experimental-compat.jar avec toutes les API de coroutines exp\u00e9rimentales. Nous allons le publier sur maven et l'inclure dans la distribution Kotlin aux c\u00f4t\u00e9s de la biblioth\u00e8que standard. Pour le moment, nous l'avons publi\u00e9 dans le r\u00e9f\u00e9rentiel bintray avec les artefacts 1.4-M1.\r\nSuppression de l'op\u00e9rateur mod obsol\u00e8te\r\nAutre fonction obsol\u00e8te\u00a0: l'op\u00e9rateur mod sur les types num\u00e9riques qui calcule le reste apr\u00e8s une op\u00e9ration de division. Dans Kotlin 1.1, il a \u00e9t\u00e9 remplac\u00e9 par la fonction rem(). Nous le supprimons maintenant compl\u00e8tement de la biblioth\u00e8que standard.\r\nObsolescence des conversions de types flottants en Byte et Short\r\nLa biblioth\u00e8que standard contient des fonctions pour convertir des nombres \u00e0 virgule flottante en types entiers\u00a0: toInt(), toShort(), toByte(). Les conversions de nombres \u00e0 virgule flottante en types Short et Byte pourraient entra\u00eener des r\u00e9sultats inattendus en raison de la plage de valeurs \u00e9troite et de la taille plus petite des variables. Pour \u00e9viter de tels probl\u00e8mes, \u00e0 partir de la version 1.4-M1, nous d\u00e9marrons l'obsolescence des fonctions toShort() et toByte() appel\u00e9es sur des types Double et Float. Si vous avez encore besoin de convertir des nombres \u00e0 virgule flottante en Byte ou Short, utilisez la conversion en deux \u00e9tapes\u00a0: vers le type Int puis vers le type cible.\r\nAPI de r\u00e9flexion commune\r\nNous avons remani\u00e9 l'API de r\u00e9flexion commune. D\u00e9sormais, elle ne contient que les membres disponibles sur les trois plateformes cibles (JVM, JS, Native) afin de vous garantir que le m\u00eame code fonctionne sur toutes les plateformes.\r\nNouveaux contrats pour la fonction use() et les fonctions de mesure du temps\r\nNous \u00e9largissons l'utilisation des contrats dans la biblioth\u00e8que standard. Dans 1.4-M1, nous avons ajout\u00e9 des contrats d\u00e9clarant une ex\u00e9cution unique d'un bloc de code pour la fonction use() et pour les fonctions de mesure du temps measureTimeMillis() et measureNanoTime().\r\nConfigurations Proguard pour les r\u00e9flexions Kotlin\r\nNous avons int\u00e9gr\u00e9 des configurations Proguard\/R8 pour Kotlin Reflection dans kotlin-reflect.jar dans la version 1.4-M1. Gr\u00e2ce \u00e0 cela, la plupart des projets Android utilisant R8 ou Proguard devraient fonctionner avec kotlin-reflect sans avoir \u00e0 recourir \u00e0 aucun tour de magie pour la configuration. Vous n'avez plus besoin de copier-coller les r\u00e8gles de Proguard pour les composants internes kotlin-reflect. Mais notez que vous devez encore r\u00e9pertorier explicitement toutes les API impliqu\u00e9es dans vos r\u00e9flexions.\r\nKotlin\/JVM\r\nDepuis la version 1.3.70, Kotlin a pu g\u00e9n\u00e9rer des annotations de type dans le bytecode JVM (version cible 1.8+), afin qu'elles soient disponibles au moment de l'ex\u00e9cution. Cette fonctionnalit\u00e9 \u00e9tait demand\u00e9e par la communaut\u00e9 depuis un certain temps car elle facilite l'utilisation de certaines biblioth\u00e8ques Java existantes et donne plus de pouvoir aux auteurs de nouvelles biblioth\u00e8ques.\r\n\r\nDans l'exemple suivant, l'annotation @ Foo sur le type String peut \u00eatre \u00e9mise dans le bytecode puis utilis\u00e9e par le code de la biblioth\u00e8que\u00a0:\r\n@Target(AnnotationTarget.TYPE)\r\nannotation class Foo\r\n\r\nclass A {\r\n    fun foo(): @Foo String = \"OK\"\r\n}\r\n\r\nPour en savoir plus sur l'\u00e9mission d'annotations de type dans le bytecode, reportez-vous \u00e0 la section correspondante de l'article de blog sur la sortie de Kotlin 1.3.70.\r\nKotlin\/JS\r\nPour Kotlin\/JS, ce jalon comprend quelques modifications de Gradle DSL, et c'est la premi\u00e8re version \u00e0 inclure le nouveau backend du compilateur IR, qui permet des optimisations et de nouvelles fonctionnalit\u00e9s.\r\nModifications de Gradle DSL\r\nDans les plugins Gradle kotlin.js et multiplatform, un nouveau param\u00e8tre important a \u00e9t\u00e9 introduit. Dans le bloc cible de votre fichier build.gradle.kts, le param\u00e8tre produceExecutable() est d\u00e9sormais disponible, et n\u00e9cessaire si vous souhaitez g\u00e9n\u00e9rer des artefacts .js pendant votre build\u00a0:\r\nkotlin {\r\n    target {\r\n        useCommonJs()\r\n\r\n        produceExecutable()\r\n        \r\n        browser {}\r\n    }\r\n}\r\n\r\nVous pouvez omettre produceExecutable() si vous r\u00e9digez une biblioth\u00e8que Kotlin\/JS. Lorsque vous utilisez le nouveau backend du compilateur IR (plus de d\u00e9tails \u00e0 ce sujet ci-dessous), l'omission de ce param\u00e8tre signifie qu'aucun fichier JS ex\u00e9cutable ne sera g\u00e9n\u00e9r\u00e9 (et, dans ces conditions, le processus de build s'ex\u00e9cutera plus rapidement). Un fichier klib est g\u00e9n\u00e9r\u00e9 dans le dossier build\/libs. Il peut \u00eatre utilis\u00e9 \u00e0 partir d'autres projets Kotlin\/JS, ou en tant que d\u00e9pendance dans le m\u00eame projet. Si vous ne sp\u00e9cifiez pas explicitement produceExecutable(), ce comportement se produit par d\u00e9faut.\r\n\r\nL'utilisation de produceExecutable() g\u00e9n\u00e9rera du code ex\u00e9cutable \u00e0 partir de l'\u00e9cosyst\u00e8me JavaScript, soit avec son propre point d'entr\u00e9e, soit en tant que biblioth\u00e8que JavaScript. Cela g\u00e9n\u00e9rera les fichiers JavaScript, qui peuvent s'ex\u00e9cuter dans un interpr\u00e9teur de n\u0153uds, \u00eatre int\u00e9gr\u00e9s dans une page HTML et ex\u00e9cut\u00e9s dans le navigateur, ou utilis\u00e9s comme d\u00e9pendances \u00e0 partir de projets JavaScript.\r\n\r\nNotez que lors du ciblage du nouveau backend du compilateur IR (plus de d\u00e9tails ci-dessous), produceExecutable() g\u00e9n\u00e9rera toujours un seul fichier .js ind\u00e9pendant par cible. Actuellement, il n'y a pas de support pour la d\u00e9duplication ou le fractionnement de code entre plusieurs artefacts g\u00e9n\u00e9r\u00e9s. Vous pouvez vous attendre \u00e0 ce que le comportement de produceExecutable() change dans les prochains jalons. Le nom de cette option est \u00e9galement susceptible de changer \u00e0 l'avenir.\r\nNouveau backend\r\nKotlin 1.4-M1 est la premi\u00e8re version \u00e0 inclure le nouveau backend du compilateur IR pour la cible Kotlin\/JS. Ce backend est le fondement d'optimisations consid\u00e9rablement am\u00e9lior\u00e9es et le facteur d\u00e9terminant pour certains changements dans les interactions entre Kotlin\/JS et JavaScript\/TypeScript. Les fonctionnalit\u00e9s mises en \u00e9vidence ci-dessous ciblent toutes le nouveau backend du compilateur IR. Bien qu'il ne soit pas encore activ\u00e9 par d\u00e9faut, nous vous encourageons \u00e0 l'essayer avec vos projets, \u00e0 commencer \u00e0 pr\u00e9parer vos biblioth\u00e8ques pour le nouveau backend, et bien s\u00fbr \u00e0 nous faire part de vos commentaires et \u00e0 nous rapporter les probl\u00e8mes que vous pourriez rencontrez.\r\nUtiliser le nouveau backend\r\nPour commencer \u00e0 utiliser le nouveau backend, d\u00e9finissez l'indicateur suivant dans votre fichier gradle.properties\u00a0:\r\nkotlin.js.compiler=ir\r\n\r\nSi vous devez cr\u00e9er des biblioth\u00e8ques pour le backend du compilateur IR et le backend par d\u00e9faut, vous pouvez \u00e9galement d\u00e9finir cet indicateur sur both. L'action de cet indicateur est pr\u00e9sent\u00e9e dans la section de cet article de blog intitul\u00e9e \u201cMode both\u201d. L'indicateur est n\u00e9cessaire car le nouveau backend du compilateur et le backend par d\u00e9faut ne sont pas compatibles avec les binaires.\r\nPas de compatibilit\u00e9 binaire\r\nL'un des changements majeurs apport\u00e9s par le nouveau backend du compilateur IR est l'absence de compatibilit\u00e9 binaire avec le backend par d\u00e9faut. Cette absence de compatibilit\u00e9 entre les deux backends pour Kotlin\/JS signifie qu'une biblioth\u00e8que cr\u00e9\u00e9e avec le nouveau backend du compilateur IR ne peut pas \u00eatre utilis\u00e9e \u00e0 partir du backend par d\u00e9faut, et vice versa.\r\n\r\nSi vous souhaitez utiliser le backend du compilateur IR pour votre projet, vous devez mettre \u00e0 jour toutes les d\u00e9pendances de Kotlin vers des versions qui prennent en charge ce nouveau backend. Les biblioth\u00e8ques publi\u00e9es par JetBrains pour Kotlin 1.4-M1 ciblant Kotlin\/JS contiennent d\u00e9j\u00e0 tous les artefacts requis pour une utilisation avec le nouveau backend du compilateur IR. S'ils d\u00e9pendent d'une telle biblioth\u00e8que, les artefacts corrects sont automatiquement s\u00e9lectionn\u00e9s par Gradle (c'est-\u00e0-dire qu'il n'est pas n\u00e9cessaire de sp\u00e9cifier une coordonn\u00e9e sp\u00e9cifique \u00e0 l'IR). Veuillez noter que certaines biblioth\u00e8ques, telles que kotlin-wrappers, rencontrent des probl\u00e8mes avec le nouveau backend du compilateur IR car elles s'appuient sur des caract\u00e9ristiques sp\u00e9cifiques du backend par d\u00e9faut. Nous en sommes conscients et cherchons \u00e0 am\u00e9liorer cette fonctionnalit\u00e9.\r\n\r\nSi vous \u00eates un auteur de biblioth\u00e8que et que vous cherchez \u00e0 assurer une compatibilit\u00e9 avec le backend du compilateur actuel, ainsi qu'avec le nouveau backend du compilateur IR, consultez \u00e9galement la section \"Mode both\" de cet article de blog.\r\n\r\nDans la section suivante, nous pr\u00e9sentons de mani\u00e8re plus d\u00e9taill\u00e9e certains des avantages et diff\u00e9rences du nouveau compilateur.\r\nDCE optimis\u00e9\r\nLe nouveau backend du compilateur IR est capable de r\u00e9aliser des optimisations beaucoup plus importantes que celles du backend par d\u00e9faut. Le code g\u00e9n\u00e9r\u00e9 fonctionne mieux avec les analyseurs statiques et il est m\u00eame possible de l'ex\u00e9cuter \u00e0 partir du nouveau backend du compilateur IR \u00e0 l'aide du Closure Compiler de Google et d'utiliser ses optimisations de mode avanc\u00e9 (notez toutefois que le plugin Kotlin\/JS Gradle ne fournit pas de prise en charge sp\u00e9cifique pour cela).\r\n\r\nLe changement le plus visible ici concerne la taille du code des artefacts g\u00e9n\u00e9r\u00e9s. Une m\u00e9thode am\u00e9lior\u00e9e d'\u00e9limination du code mort permet une r\u00e9duction consid\u00e9rable des artefacts. Par exemple, cela r\u00e9duit un programme \u201cHello, World!\u201d en Kotlin\/JS \u00e0 un peu moins de 1,7 Ko. Pour les projets (d\u00e9mo) plus complexes, tels que dans cet exemple utilisant kotlinx.coroutines, les chiffres ont \u00e9galement radicalement chang\u00e9 et parlent d'eux-m\u00eames\u00a0:\r\n\r\n\r\n\r\n\r\nBackend par d\u00e9faut\r\nBackend IR\r\n\r\n\r\n\r\n\r\nApr\u00e8s compilation\r\n3,9 Mio\r\n1,1 Mio\r\n\r\n\r\nApr\u00e8s DCE JS\r\n713 Kio\r\n430 Kio\r\n\r\n\r\nApr\u00e8s bundle\r\n329 Kio\r\n184 Kio\r\n\r\n\r\nApr\u00e8s ZIP\r\n74 Kio\r\n40 Kio\r\n\r\n\r\n\r\nSi vous n'\u00eates pas encore convaincu, essayez vous-m\u00eame. DCE et le regoupement sont activ\u00e9s par d\u00e9faut pour les deux backends dans Kotlin 1.4-M1\u00a0!\r\nExporter des d\u00e9clarations vers JavaScript\r\nLorsque vous utilisez le backend du compilateur IR, les d\u00e9clarations marqu\u00e9es comme publiques ne sont plus export\u00e9es automatiquement (pas m\u00eame une version avec un nom modifi\u00e9). En effet, le mod\u00e8le de monde clos du compilateur IR suppose que les d\u00e9clarations export\u00e9es sont sp\u00e9cifiquement annot\u00e9es. C'est l'un des facteurs qui facilite les optimisations telles que celle mentionn\u00e9e ci-dessus.\r\n\r\nPour rendre une d\u00e9claration top-level disponible en externe sur JavaScript ou TypeScript, utilisez l'annotation @JsExport. Dans l'exemple suivant, nous rendons KotlinGreeter (et ses m\u00e9thodes) et farewell() disponibles \u00e0 partir de JavaScript, mais r\u00e9servons l'acc\u00e8s \u00e0 secretGreeting() \u00e0 Kotlin\u00a0:\r\npackage blogpost\r\n\r\n@JsExport\r\nclass KotlinGreeter(private val who: String) {\r\n    fun greet() = \"Hello, $who!\"\r\n}\r\n\r\n@JsExport\r\nfun farewell(who: String) = \"Bye, $who!\"\r\n\r\nfun secretGreeting(who: String) = \"Sup, $who!\" \/\/ uniquement en Kotlin\u00a0!\r\n\r\nPreview\u00a0: d\u00e9finitions de TypeScript\r\nAutre fonctionnalit\u00e9 du nouveau compilateur IR Kotlin\/JS que nous sommes ravis de vous pr\u00e9senter\u00a0: la g\u00e9n\u00e9ration de d\u00e9finitions TypeScript \u00e0 partir de code Kotlin. Ces d\u00e9finitions peuvent \u00eatre utilis\u00e9es par les EDI et outils JavaScript lorsque vous travaillez sur des applications hybrides pour fournir la saisie semi-automatique, prendre en charge les analyseurs statiques et faciliter l'inclusion de code Kotlin dans les projets JS et TS.\r\n\r\nPour les d\u00e9clarations dtop-level annot\u00e9es par @JsExport (voir ci-dessus) dans un projet configur\u00e9 pour utiliser produceExecutable(), un fichier .d.ts avec les d\u00e9finitions TypeScript sera g\u00e9n\u00e9r\u00e9. Pour le snippet ci-dessus, elles ressemblent \u00e0 ceci\u00a0:\r\n\/\/ [...]\r\nnamespace blogpost {\r\n    class KotlinGreeter {\r\n        constructor(who: string)\r\n        greet(): string\r\n    }\r\n    function farewell(who: string): string\r\n}\r\n\/\/ [...]\r\n\r\nDans Kotlin 1.4-M1, ces d\u00e9clarations se trouvent dans build\/js\/packages \/\/kotlin \u00e0 c\u00f4t\u00e9 du code JavaScript Web non compress\u00e9 correspondant. Veuillez noter que puisqu'il ne s'agit que d'une preview, ils ne sont pas ajout\u00e9s au dossier distributions par d\u00e9faut pour l'instant. Ce comportement devrait changer \u00e0 l'avenir.\r\nMode both\r\nPour faciliter l'adoption du nouveau backend du compilateur IR pour les responsables de biblioth\u00e8que, nous avons introduit un param\u00e8tre suppl\u00e9mentaire pour l'indicateur kotlin.js.compiler dans gradle.properties\u00a0:\r\nkotlin.js.compiler=both\r\n\r\nEn mode both, le backend du compilateur IR et le backend du compilateur par d\u00e9faut sont tous deux utilis\u00e9s lors de la cr\u00e9ation d'une biblioth\u00e8que \u00e0 partir de vos sources (d'o\u00f9 le nom). Cela signifie que les fichiers klib avec Kotlin IR mais aussi les fichiers js pour le compilateur par d\u00e9faut seront g\u00e9n\u00e9r\u00e9s. S'il est publi\u00e9 sous la m\u00eame coordonn\u00e9e Maven, Gradle choisira automatiquement le bon artefact en fonction du cas d'utilisation\u00a0: js pour l'ancien compilateur, klib pour le nouveau. Vous pouvez donc compiler et publier votre biblioth\u00e8que avec le nouveau backend du compilateur IR pour les projets qui ont d\u00e9j\u00e0 \u00e9t\u00e9 mis \u00e0 niveau vers Kotlin 1.4-M1 et qui utilisent l'un des deux backends du compilateur. Cela permet de garantir que vous ne romprez pas l'exp\u00e9rience pour ceux de vos utilisateurs qui utilisent toujours le backend par d\u00e9faut - parce qu'ils ont mis \u00e0 niveau leur projet vers la version 1.4-M1.\r\n\r\nVeuillez noter qu'un probl\u00e8me persiste actuellement, qui emp\u00eache l'EDI de r\u00e9soudre correctement les r\u00e9f\u00e9rences de biblioth\u00e8que lorsque la d\u00e9pendance et votre projet actuel sont g\u00e9n\u00e9r\u00e9s en mode both. Nous sommes conscients de ce probl\u00e8me et le corrigerons prochainement.\r\nKotlin\/Native\r\nPrise en charge des g\u00e9n\u00e9riques Objective-C par d\u00e9faut\r\nLes versions pr\u00e9c\u00e9dentes de Kotlin fournissaient une prise en charge exp\u00e9rimentale pour les g\u00e9n\u00e9riques dans l'interop\u00e9rabilit\u00e9 Objective-C. Pour g\u00e9n\u00e9rer un en-t\u00eate de framework avec des g\u00e9n\u00e9riques \u00e0 partir du code Kotlin, vous avez d\u00fb utiliser l'option de compilateur -Xobjc-generics. Dans la version 1.4-M1, ce comportement devient la valeur par d\u00e9faut. Dans certains cas, cela peut casser un code Objective-C ou Swift existant s'il appelle les frameworks Kotlin. Pour que l'en-t\u00eate du framework soit \u00e9crit sans g\u00e9n\u00e9riques, ajoutez l'option de compilateur -Xno-objc-generics.\r\nbinaries.framework {\r\n     freeCompilerArgs += \"-Xno-objc-generics\"\r\n}\r\n\r\nVeuillez noter que toutes les sp\u00e9cificit\u00e9s et limitations r\u00e9pertori\u00e9es dans la documentation restent valables.\r\nChangements de la gestion des exceptions dans l'interop\u00e9rabilit\u00e9 Objective-C\/Swift\r\nDans la version 1.4, nous modifierons l\u00e9g\u00e8rement l'API Swift g\u00e9n\u00e9r\u00e9e \u00e0 partir de Kotlin en ce qui concerne la traduction des exceptions. Il existe une diff\u00e9rence fondamentale entre Kotlin et Swift concernant la gestion des erreurs . Toutes les exceptions Kotlin sont non v\u00e9rifi\u00e9es, tandis que Swift n'a que des erreurs v\u00e9rifi\u00e9es. Ainsi, pour rendre le code Swift conscient des exceptions attendues, les fonctions Kotlin doivent \u00eatre signal\u00e9es par une annotation @Throws sp\u00e9cifiant une liste de classes d'exceptions potentielles.\r\nLors de la compilation vers Swift ou le framework Objective-C, les fonctions qui comportent des annotations @Throws ou en h\u00e9ritent sont repr\u00e9sent\u00e9es comme des m\u00e9thodes produisant NSError* dans Objective-C et comme des m\u00e9thodes throws dans Swift.\r\nAuparavant, toute exception autre que RuntimeException et Error \u00e9taient converties en NSError. Dans la version 1.4-M1, nous avons chang\u00e9 ce comportement. D\u00e9sormais, NSError est lev\u00e9e uniquement pour les exceptions qui sont des instances de classes sp\u00e9cifi\u00e9es en tant que param\u00e8tres de l'annotation @Throws (ou de leurs sous-classes). Les autres exceptions Kotlin qui atteignent Swift\/Objective-C sont consid\u00e9r\u00e9es comme non g\u00e9r\u00e9es et provoquent l'arr\u00eat du programme.\r\nAm\u00e9liorations des performances\r\nNous nous effor\u00e7ons d'am\u00e9liorer continuellement les performances globales de la compilation et de l'ex\u00e9cution de Kotlin\/Native. Dans la version 1.4-M1, nous vous proposons le nouvel allocateur d'objets, jusqu'\u00e0 deux fois plus rapide sur certains comparateurs. Actuellement, le nouvel allocateur est exp\u00e9rimental et n'est pas utilis\u00e9 par d\u00e9faut\u00a0; vous pouvez l'activer en utilisant l'option du compilateur -Xallocator=mimalloc.\r\nCompatibilit\u00e9\r\nNotez que Kotlin 1.4 n'est pas r\u00e9trocompatible avec la version 1.3 dans certains cas particuliers. Tous ces cas ont \u00e9t\u00e9 soigneusement examin\u00e9s par le comit\u00e9 du langage et seront r\u00e9pertori\u00e9s dans le \"guide de compatibilit\u00e9\" (similaire \u00e0 celui-ci). Pour le moment, vous pouvez trouver cette liste dans YouTrack.\r\n\r\nLes r\u00e8gles de r\u00e9solution des surcharges peuvent changer l\u00e9g\u00e8rement. Si vous avez plusieurs fonctions avec les m\u00eames noms et des signatures diff\u00e9rentes, celle qui est appel\u00e9e dans Kotlin 1.4 peut \u00eatre diff\u00e9rente de celle qui a \u00e9t\u00e9 choisie dans Kotlin 1.3. Toutefois, cela ne se produit que dans des cas tr\u00e8s particuliers et nous nous attendons \u00e0 une tr\u00e8s faible occurrence en pratique. Nous supposons \u00e9galement qu'en pratique, les fonctions surcharg\u00e9es se comportent de mani\u00e8re similaire, s\u2019appelant \u00e9ventuellement les unes les autres. C\u2019est pourquoi ces modifications ne devraient pas affecter le comportement du programme. Mais faites attention \u00e0 cela si vous aimez \u00e9crire du code complexe avec des g\u00e9n\u00e9riques et de nombreuses surcharges \u00e0 diff\u00e9rents niveaux. Tous les cas de ce type seront r\u00e9pertori\u00e9s dans le guide de compatibilit\u00e9 mentionn\u00e9 ci-dessus.\r\nNotes de pr\u00e9-version\r\nNotez que les garanties de r\u00e9trocompatibilit\u00e9 ne concernent pas les versions pr\u00e9liminaires. Les fonctionnalit\u00e9s et l'API peuvent changer dans les versions ult\u00e9rieures. Lorsque nous atteindrons un RC final, tous les binaires produits par les versions pr\u00e9liminaires seront interdits par le compilateur et vous devrez recompiler tout ce qui a \u00e9t\u00e9 compil\u00e9 par la version 1.4 \u2011 Mx.\r\nComment essayer\r\nComme toujours, vous pouvez essayer Kotlin en ligne sur play.kotl.in.\r\n\r\nDans IntelliJ IDEA et Android Studio, vous pouvez mettre \u00e0 jour le plugin Kotlin vers la version 1.4-M1. Voir comment proc\u00e9der.\r\n\r\nSi vous souhaitez travailler sur des projets existants qui ont \u00e9t\u00e9 cr\u00e9\u00e9s avant d'installer la version pr\u00e9liminaire, vous devez configurer votre build pour la version Prewiew dans Gradle ou Maven.\r\n\r\nVous pouvez t\u00e9l\u00e9charger le compilateur de ligne de commande sur la page de la version sur Github.\r\n\r\nVous pouvez utiliser les versions suivantes des biblioth\u00e8ques publi\u00e9es avec cette version du langage\u00a0:\r\n\r\n\tVersion kotlinx.atomicfu\u00a0: 0.14.2-1.4-M1\r\n\tVersion kotlinx.coroutines\u00a0: 1.3.5-1.4-M1\r\n\tVersion kotlinx.serialization\u00a0: 0.20.0-1.4-M1\r\n\tVersion ktor\u00a0: 1.3.2-1.4-M1\r\n\r\nLes d\u00e9tails de la version et la liste des biblioth\u00e8ques compatibles sont \u00e9galement disponibles ici.\r\nFaites-nous part de vos commentaires\r\nNous vous serions tr\u00e8s reconnaissants de nous signaler les bugs sur notre outil de suivi de tickets YouTrack. Nous ferons de notre mieux pour r\u00e9soudre tous les probl\u00e8mes importants avant la version finale, afin que vous n'ayez pas \u00e0 attendre la prochaine version de Kotlin.\r\n\r\nSi vous avez des questions et souhaitez participer aux discussions, nous vous invitons \u00e0 rejoindre le canal #eap du Slack Kotlin (demandez une invitation ici). Vous pouvez \u00e9galement recevoir des notifications concernant les nouvelles builds de la Preview sur ce canal.\r\n\r\nFaison \u00e9voluer Kotlin ensemble !\r\nContributions externes\r\nNous tenons \u00e0 remercier particuli\u00e8rement Zac Sweers pour sa contribution \u00e0 l'int\u00e9gration des configurations Proguard dans kotlin-reflect.\r\n\r\nNous remercions tous nos contributeurs externes dont les requ\u00eates pull ont \u00e9t\u00e9 incluses dans cette version\u00a0:\r\n\r\n\tSteven Sch\u00e4fer\r\n\tToshiaki Kameyama\r\n\tpyos\r\n\tMads Ager\r\n\tMark Punzalan\r\n\tJuan Chen\r\n\tKristoffer Andersen\r\n\tAlfredo Delli Bovi\r\n\tJinseong Jeon\r\n\tJonathan Leitschuh\r\n\tSebastian Schuberth\r\n\tIvan Gavrilovic\r\n\tDavid Schreiber-Ranner\r\n\tMiguel Serra\r\n\tAlex Chmyr\r\n\tFleshgrinder\r\n\tAleksey Kladov\r\n\tWill Boyd\r\n\tDominic Fischer\r\n\tKenji Tomita\r\n\tSt\u00e9phane Nicolas\r\n\tTillmann Berg\r\n\tKevin Bierhoff\r\n\tTsvetan","protected":false},"excerpt":{"rendered":"Nous avons le plaisir de vous pr\u00e9senter Kotlin 1.4-M1, la Preview de la prochaine version majeure de Kotlin.Il y a quelques mois, nous vous avions inform\u00e9 de Ce que Kotlin 1.4 allait vous r\u00e9server","protected":false},"author":{"name":"Delphine Massenhove","link":"https:\/\/blog.jetbrains.com\/fr\/author\/delphine-massenhovejetbrains-com"},"featured_media":34259,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"inline_featured_image":false,"footnotes":""},"categories":[907],"tags":[600,5319],"cross-post-tag":[],"acf":[],"featured_image":"https:\/\/blog.jetbrains.com\/wp-content\/uploads\/2020\/04\/fr-Kotlin-preview-1.4-M1.png","_links":{"self":[{"href":"https:\/\/blog.jetbrains.com\/fr\/wp-json\/wp\/v2\/posts\/34258"}],"collection":[{"href":"https:\/\/blog.jetbrains.com\/fr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.jetbrains.com\/fr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.jetbrains.com\/fr\/wp-json\/wp\/v2\/users\/813"},{"embeddable":true,"href":"https:\/\/blog.jetbrains.com\/fr\/wp-json\/wp\/v2\/users\/813"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.jetbrains.com\/fr\/wp-json\/wp\/v2\/comments?post=34258"}],"version-history":[{"count":0,"href":"https:\/\/blog.jetbrains.com\/fr\/wp-json\/wp\/v2\/posts\/34258\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/blog.jetbrains.com\/fr\/wp-json\/wp\/v2\/media\/34259"}],"wp:attachment":[{"href":"https:\/\/blog.jetbrains.com\/fr\/wp-json\/wp\/v2\/media?parent=34258"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.jetbrains.com\/fr\/wp-json\/wp\/v2\/categories?post=34258"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.jetbrains.com\/fr\/wp-json\/wp\/v2\/tags?post=34258"},{"taxonomy":"cross-post-tag","embeddable":true,"href":"https:\/\/blog.jetbrains.com\/fr\/wp-json\/wp\/v2\/cross-post-tag?post=34258"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}