Type inference rules
Here we’ll continue explaining how Crystal assigns types to each variable and expression of your program. This post is a bit long, but in the end it’s just about making Crystal behave in the most intuitive way for the programmer, to make it behave as similar as possible to Ruby.
We’ll start with literals, C functions and some primitives. Then we’ll continue with flow
control structures, like if, while, and blocks. Then we’ll talk about the special
NoReturn type and type filters.
Literals
Literals have a type of their own, known by the compiler:
true # Boolean
1 # Int32
"hello" # String
1.5 # Float64
C functions
When you define a C function you must tell the compiler its types:
lib C
fun sleep(seconds : UInt32) : UInt32
end
sleep(1_u32) # sleep has type UInt32
allocate
The allocate primitive gives you an uninitialized instance of an object:
class Foo
def initialize(@x)
end
end
Foo.allocate # Foo.allocate has type Foo
You don’t normally invoke it directly. Instead, you invoke new, which
is automatically generated by the compiler to something like this:
class Foo
def self.new(x)
foo = allocate
foo.initialize(x)
foo
end
def initialize(@x)
end
end
Foo.new(1)
A similar primitive is Pointer#malloc, which gives you a typed pointer to a
memory region:
Pointer(Int32).malloc(10) # has type Pointer(Int32)
Variables
Next, when you assign an expression to a variable, the variable will be bound to that expression’s type (if the expresision’s type changes, so the variable’s type changes).
a = 1 # 1 is Int32, so a is Int32
The compiler tries to be as smart as possible when you use variables. For example, you can assign multiple times to a variable:
a = 1 # a is Int32
a.abs # ok, Int32 has a method 'abs'
a = "hello" # a is now String
a.size # ok, String has a method 'size'
To achieve this, the compiler remembers which expression was the last one assigned
to a variable. In the above example, after the first line the compiler knows that
a has type Int32, so a call to abs is valid. In the third line we assign
a String to it, so the compiler remembers this and, on the fourth line, it’s perfectly
valid to invoke size on it.
Additionally, the compiler remembers that both an Int32 and a String were
assigned to a. When generating LLVM code, the compiler will represent a
as a union type that can be Int32 or String. It would be something like this in C:
struct Int32OrString {
int type_id;
union {
int int_value;
string string_value;
} data;
}
This might seem inefficient if we continually assign different types to the same variable.
However, the compiler knows that when you invoked abs, a was an Int32, so it never
checks the type_id field: it directly uses the int_value field. LLVM notices this
and optimizes this out, so in the generated code there will never be a union (the type_id
field is never read).
Going back to Ruby, if you assign a variable multiple times in a row, the last value (and type) is the one that counts for subsequent calls. Crystal mimics this behaviour. A variable then just becomes a name for the last expression that we assigned to.
If
Let’s take a piece of Ruby code and analyze it:
if some_condition
a = 1
a.abs
else
a = "hello"
a.size
end
a.size
In Ruby, the only line that can fail at runtime is the last one. The first call to abs
will never fail, as an Int32 was assigned to a. The first call to size will
also never fail, as a String was assigned to a. However, after the if, a can
either be an Int32 or a String.
So Crystal tries to keep this intuitive reasoning about a’s type. When a variable is assigned
inside an if’s then or else branch, the compiler knows that it will continue to have that type until the if
ends or until it is assigned a new expression. When an if ends, the compiler will let a
have the type of the last expressions that it was assigned to in each branch.
The last line in Crystal will give a compiler error: “undefined method ‘size’ for Int32”.
That’s because even though String has a size method, Int32 doesn’t.
In designing the language we had two choices: make the above a compile-time error (like now) or just make it a runtime error (like in Ruby). We believe it’s better to make it a compile-time error. In some cases you might know better than the compiler and you will be sure that a variable has the type that you might think. But in some cases the compiler will let you know that you overlooked a case or some logic, and you’ll thank it for that.
The if has some more cases to take into account. For example, the variable a might not exist
before the if. In this case, if it’s not assigned in one of the branches, at the end of the
if it will also contain the Nil type if it’s read:
if some_condition
a = 1
end
a # here a is Int32 or Nil
This, again, mimics Ruby’s behaviour.
Finally, an if’s type is the union of the last expressions in both branches. If a branch
is missing, it’s considered to have a Nil type.
While
A while is in a way similar to an if:
a = 1
while some_condition
a = "hello"
end
a # here a is Int32 or String
That’s because some_condition might be falsy the first time.
However, since a while is a loop there are some more things to consider. For example,
the last expression assigned to a variable inside a while determines the type of that
variable in the next iteration. In this way, the type at the beginning of the loop
will be a union of the type before the loop and the type after the loop:
a = 1
while some_condition
a # here a is actually Int32 or String
a = false # here a is Bool
a = "hello" # here a is String
a.size # ok, a is String
end
a # here a is Int32 or String
Some other things to consider inside a while are break and next. A break
makes the types right before the break add to the type at the exit of the while:
a = 1
while some_condition
a # here a is Int32 or Bool
if some_other_condition
a = "hello" # we break, so at the exit a can also be String
break
end
a = false # here a is Bool
end
a # here a is Int32 or String or Bool
A next adds the type to the beginning of the while:
a = 1
while some_condition
a # here a is Int32 or String or Bool
if some_other_condition
a = "hello" # we next, so in the next iteration a can be String
next
end
a = false # here a is Bool
end
a # here a is Int32 or String or Bool
Blocks
Blocks are very similar to a while: they can be executed zero or more times. So
the logic for variables’ types is very similar to that of a while.
NoReturn
There’s a mysterious type in Crystal called NoReturn. One such example is
C’s exit function:
lib C
fun exit(status : Int32) : NoReturn
end
C.exit(1) # this is NoReturn
puts "hello" # this will never be executed
Another very useful method that is NoReturn is raise: raising an exception.
The type basically means: after this point there’s nothing else. Nothing gets returned,
and nothing that comes afterwars is executed (of course, a rescue will be executed
if there’s one surrounding the code, but the normal path won’t be executed).
The compiler knows about NoReturn. For example, take a look at the following code:
a = some_int
if a == 1
a = "hello"
puts a.size # ok
raise "Boom!"
else
a = 2
end
a # here a can only be Int32
Remember that after an if a variable’s type is the union of the types of
both branches. However, since the first branch ends there, because raise is NoReturn,
the compiler knows that code after the if, if that branch is taken, will never be
executed. So it can definitely say: a will only have the type of the else
branch.
The same logic applies when you have return, break or next inside an if.
Also, when you define a method whose type is NoReturn, that method is in turn NoReturn:
def raise_boom
raise "Boom!"
end
if some_condition
a = 1
else
raise_boom
end
a.abs # ok
Union of NoReturn
Remember that an if’s type is the union of the last expressions of the if’s branches.
What type has the following if (and consequently the a variable)?
a = if some_condition
raise "Boom!"
else
1
end
a # a is...?
Well, the then branch is definitely NoReturn. The else branch is definitely
Int32. We could conclude then that a has type NoReturn or Int32.
However, NoReturn means that nothing gets executed afterwards. So a can only
be Int32 at the end of the previous snippet, and that’s how the compiler behaves.
With this we can implement a little method called not_nil!. Here it is:
class Object
def not_nil!
self
end
end
class Nil
def not_nil!
raise "Nil assertion failed"
end
end
a = some_condition ? 1 : nil
a.not_nil!.abs # compiles!
a’s type is Int32 or Nil. One thing that we didn’t say yet is that when you
have a union type and you invoke a method on it, and all types respond to that method, the resulting
type is the union of the types of each method.
In this case, a.not_nil! will have the type Int32 if a is Int32, or
NoReturn if it’s Nil (because of the raise). Combining these types just
gives Int32, so the above code is perfectly valid. And that’s how you can discard Nil
from a variable and turn it into a runtime exception if it turns out to be nil. No special language
construct is needed. All is made with the logic explained so far.
Type filters
Now, what if we want to execute a method on a variable whose type is Int32 or Nil,
but only if that variable is Int32. If it’s Nil, we don’t want to do anything.
We can’t use not_nil!, because that will raise a runtime exception when nil.
We can define another method, try:
class Object
def try
yield self
end
end
class Nil
def try(&block)
nil
end
end
a = some_condition ? 1 : nil
b = a.try &.abs # b is Int32 or Nil
(if you are not sure what &.abs means, read this)
Since doing something depending on whether a value is Nil or not is so common, Crystal
provides another way to do the above. This was shortly explained
here, but now we’ll explain it
better and combine it with the previous explanations.
If a variable is an if’s condition, the compiler assumes the variable is not nil
inside the then branch:
a = some_condition ? 1 : nil # a is Int32 or Nil
if a
a.abs # a is Int32
end
This makes sense: if a is truthy then it means it is not nil. Not only this,
but the compiler also makes a’s type be that one after the if, combined with
whatever type a has in the else branch. For example:
a = some_condition ? 1 : nil
if a
a.abs # ok, here a is Int32
else
a = 1 # here a is Int32
end
a.abs # ok, a can only be Int32 here
Just like a programmer expects the above to always work in Ruby (never raise an “undefined method” error in runtime), so it works in Crystal.
We call the above a “type filter”: a’s type got filtered inside the if’s
then branch by removing Nil from the possible types a can have.
Another type filter happens when you do is_a?:
a = some_condition ? 1 : nil
if a.is_a?(Int32)
a.abs # ok
end
And another type filter happens when you do responds_to?:
a = some_condition ? 1 : nil
if a.responds_to?(:abs)
a.abs # ok
end
These are special methods, known by the compiler, and that’s why the compiler is
able to filter the types. On the contrary, the method nil? is not special right now
so the following won’t work:
a = some_condition ? 1 : nil
if a.nil?
else
a.abs # should be ok, but now gives error
end
We’ll probably make nil? a special method too, so it’s more consistent with the
rest of the language and the above works. We’ll also probably make the unary ! method
special, not overloadable, so you could do:
a = some_condition ? 1 : nil
if !a
else
a.abs # should be ok, but now gives error
end
Conclusion
In conclusion, as was said in the beginning of this post, we want Crystal to behave as much as possible as Ruby, and if something is intuitive and makes sense for the programmer to make the compiler understand it too. For example:
def foo(x)
return unless x
x.abs # ok
end
a = some_condition ? 1 : nil
b = foo(a)
The above shouldn’t give you a compile time error. The programmer knows that if x
was nil inside foo, the method returns. It follows that x can never be
nil afterwards so it’s ok to invoke abs on it. How does the compiler know this?
Well, first, the compiler rewrites an unless to an if:
def foo(x)
if x
else
return
end
x.abs # ok
end
Next, inside the then branch of the if we know that x is not nil.
Inside the else branch the method returns, so we don’t care about the type of x
afterwards. So, after the if, x can only be of type Int32. This is idiomatic
code in Ruby, and so it is in Crystal if we carefully follow the language rules.
We still have to talk about methods and instance variables, but this post is already long enough so that will have to be explained in a following post. Stay tuned!