Sortie de Crystal 1.5.0, un langage de programmation compilé avec une syntaxe similaire à Ruby

Crystal est un langage de programmation orienté objet à usage général conçu et développé par Ary Borenszweig, Juan Wajnerman, Brian Cardiff et plus de 300 contributeurs. Inspirée de Ruby, la syntaxe de Crystal est un langage compilé avec une vérification de type statique, mais n'a généralement pas besoin de spécifier les types de variables ou les paramètres de méthode, et peut atteindre des performances proches de C/C++. Son type est résolu par un algorithme avancé d'inférence de type global.

Crystal 1.5.0 est sorti, cette version contient 102 modifications apportées par 23 contributeurs depuis la version 1.4.1 . Le contenu principal est le suivant :

Les paramètres des méthodes implémentant l'abstract `DEF`doivent correspondre aux noms

Pour une meilleure documentation et robustesse, les paramètres peuvent être explicitement associés à leurs noms ( ref ) :

class Foo
  def foo(name : Int32) : Nil
    p name
  end
end

Foo.new.foo name: 42

Par conséquent, il est nécessaire de considérer le nom du paramètre comme faisant partie de son interface. Cependant, avant la version 1.5.0, le compilateur ne vérifiait pas la correspondance des noms de paramètres entre l'implémentation d'une méthode abstraite et sa définition. Autrement dit, l'exemple suivant se compile sans erreurs ni avertissements :

abstract class FooAbstract
  abstract def foo(number : Int32) : Nil
end

class Foo < FooAbstract
  def foo(name : Int32) : Nil
    p name
  end
end

À partir de 1.5.0 ( #11915 ), l'exemple ci-dessus déclenchera un avertissement :

 6 | def foo(name : Int32) : Nil
             ^---
Warning: positional parameter 'name' corresponds to parameter 'number' of the overridden method FooAbstract#foo(number : Int32), which has a different name and may affect named argument passing

Restrictions de méthode pour les variables d'instance

Lorsqu'une variable d'instance se voit attribuer la valeur d'un paramètre de méthode non typé, le paramètre est limité pour partager le même type que la variable d'instance.

Par exemple le code suivant :

class Foo
  @x : Int64

  def initialize(x)
    @x = x
  end
end

Jusqu'à la version 1.4.1, xin initializen'était pas restreint, mais cela pose plusieurs problèmes :

Si l'utilisateur passe un paramètre incorrect, par exemple Foo.new 'a', au lieu de marquer l'erreur dans le paramètre 'a', il accusera x de ne pas avoir le bon type.
Par exemple, si nous passons un Int32 à la place, aucune conversion automatique n'est effectuée : Foo.new 1 échoue.
La documentation générée ne fournit pas d'indice pour le type de paramètre x.

Depuis la version 1.5.0, dans une affectation telle que @x = x, le paramètre x obtient le type de @x, résolvant efficacement les trois problèmes ci-dessus. Les détails peuvent être lus à partir de # 12103 .

Annotations autorisées sur les paramètres de méthode

Il est maintenant possible d'ajouter des commentaires aux paramètres des méthodes ou des macros. A titre d'illustration, disons qu'un linter avertira lorsque les arguments ne sont pas utilisés.

def foo(x); end  # Warning: argument `x` is not used

Nous pouvons alors signaler au linter de ne pas nous avertir dans certaines circonstances. Supposons que le linter fournisse les annotations suivantes :

annotation MaybeUnused; end

L'application de ceci au paramètre supprime l'avertissement (dans ce linter fictif particulier):

def foo(@[MaybeUnused] x); end  # OK

En savoir plus dans # 12039 .

indexeur constant pour les tuples

Lors de l'utilisation de tuples const-indexés ou de tuples nommés, le vérificateur de type déduira correctement le type exact de la valeur accédée ( #12012 ).

KEY = "s"
foo = {s: "String", n: 0}

# Before 1.5.0 this failed; it would assume the type of foo[key] to be (String | Int32)
puts foo[KEY].size

renforcer la sécurité`FILE.TEMPFILE`

Selon #12076 , la création de fichiers temporaires n'autorise pas les caractères nuls dans la chaîne des noms de fichiers.

Conformité NO_COLOR

Le compilateur et l'interpréteur prennent en charge la variable d' environnement NO_COLOR pour désactiver la sortie colorée sur le terminal. Peut être activé en définissant toute valeur non nulle sur . Les détails peuvent être trouvés dans # 11984 .NO_COLOR

Un pas de géant vers le support natif de WINDOWS

Le runtime de concurrence sous Windows est pris en charge par une boucle d'événement fonctionnelle ( #12149 ). Cela franchit une étape importante sur la voie du support natif de Windows . De plus, il existe maintenant un compatible Windows Makefile( #11773 ).

Du contenu supplémentaire peut être trouvé dans l' annonce de mise à jour :https://crystal-lang.org/2022/07/06/1.5.0-released.html .