Crystal is a general-purpose, object-oriented programming language designed and developed by Ary Borenszweig, Juan Wajnerman, Brian Cardiff, and more than 300 contributors. Inspired by Ruby, Crystal's syntax is a compiled language with static type checking, but generally does not need to specify the types of variables or method parameters, and can achieve performance close to C/C++. Its type is resolved by an advanced global type inference algorithm.
Crystal 1.5.0 has been released, this version contains 102 changes made by 23 contributors since version 1.4.1 . The main contents are as follows:
The parameters of the methods implementing the abstract DEF
must match the names
For better documentation and robustness, parameters can be explicitly associated with their names ( ref ):
class Foo
def foo(name : Int32) : Nil
p name
end
end
Foo.new.foo name: 42
Therefore, it is necessary to consider the name of the parameter as part of its interface. However, prior to 1.5.0, the compiler did not check for parameter names matching between the implementation of an abstract method and its definition. That is, the following example compiles without errors or warnings:
abstract class FooAbstract
abstract def foo(number : Int32) : Nil
end
class Foo < FooAbstract
def foo(name : Int32) : Nil
p name
end
end
As of 1.5.0 ( #11915 ), the above example will raise a warning:
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
Method Restrictions for Instance Variables
When an instance variable is assigned the value of an untyped method parameter, the parameter is restricted to share the same type as the instance variable.
For example the following code:
class Foo
@x : Int64
def initialize(x)
@x = x
end
end
Until 1.4.1, x
in initialize
was unrestricted, but this causes several problems:
- If the user passes an incorrect parameter, eg Foo.new 'a', instead of marking the error in parameter 'a', it will accuse x of not having the correct type.
- For example, if we pass an Int32 instead, no automatic conversion is performed: Foo.new 1 fails.
- The generated documentation does not provide a hint for the type of parameter x.
As of 1.5.0, in an assignment like @x = x, the parameter x gets the type of @x, effectively solving the above three problems. Details can be read from #12103 .
Annotations allowed on method parameters
It is now possible to add comments to parameters of methods or macros. As an illustration, let's say a linter will warn when arguments are not used.
def foo(x); end # Warning: argument `x` is not used
We can then signal the linter not to warn us under certain circumstances. Suppose the linter provides the following annotations:
annotation MaybeUnused; end
Applying this to the parameter removes the warning (in this particular fictitious linter):
def foo(@[MaybeUnused] x); end # OK
Learn more in #12039 .
constant indexer for tuples
When using const-indexed tuples or named tuples, the type checker will correctly infer the exact type of the value accessed ( #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
strengthen securityFILE.TEMPFILE
According to #12076 , the creation of temporary files does not allow null characters in the string of filenames.
NO_COLOR compliance
The compiler and interpreter support the NO_COLOR environment variable to disable colored output on the terminal. Can be enabled by setting any non-null value NO_COLOR
to . Details can be found in #11984 .
A giant step towards native WINDOWS support
The concurrency runtime on Windows is supported by a functional event loop ( #12149 ). This crosses an important check on the road to native Windows support . Also, there is now a Windows-compatible one Makefile
( #11773 ).
Additional content can be found in the update announcement:https://crystal-lang.org/2022/07/06/1.5.0-released.html .