[Experimental] Platform dependent int

[asterite]

For #8111

Why?

As our ongoing quest to find the optimal language with also avoiding a massive breaking change, we discussed trying out the experiment of introducing a platform-dependent Int type.

What's Int?

Here Int is a different type than any other int type, meaning you can't pass an Int64 where an Int is expected.

However, this is based on #9569 and since Int will be represented as Int32 or Int64 depending on the platform, any int type that fits inside Int32 can be automatically passed to Int. That means an Int32 variable can be passed to an Int restriction.

Given that most of the restrictions in the stdlib are Int, and because Int32 is the usual default int type used everything, changing this has a low chance of breaking everyone's code, assuming the std is fully migrated to this new approach.

How to implement this?

Implementing this is a bit tricky. One problem is that Int is currently the base type of all ints. Now we want another base type, namely IntBase to serve that purpose, and Int to be a subclass. This information is deeply embedded in the compiler so we must change that there. But we also need to change the stdlib code that assumes these things.

To accomplish that there's a new compile-time flag, platform_dependent_int that will be true when compiling the new compiler (so you don't need to pass it), but obviously it's false in the current state. With that flag we can control what the stdlib looks like.

To make things easier we introduce a couple of aliases:

• IntBase: well, this is actually the base type if platform_dependent_int is true, and it's aliases to Int if it's false
• DefaultInt: this is Int when platform_dependent_int is true, and Int32 when it's false

Also, the type of an integer literal like 1 or 123 is now Int in the new approach.

Next I tried compiling an empty program. That already didn't compile and so I started changing a lot of Int32 to DefaultInt. That means we aren't changing anything if platform_dependent_int is false, but we are making it be Int if the flag is on. Eventually I managed to compile an empty program (with the default prelude and runtime), so this already works fine:

[10, 20, 30].each_with_index do |x, i|
  puts "#{x}) #{i}"
  p! typeof(x), typeof(i)
end

Obvious output:

10) 0
typeof(x) # => Int
typeof(i) # => Int
20) 1
typeof(x) # => Int
typeof(i) # => Int
30) 2
typeof(x) # => Int
typeof(i) # => Int

Oh, a small note: for now Int is actually implemented a Int64 regardless of the platform, just to make things easier for me. Changing that to Int32 is very easy.

Another note: to_i now returns Int (or, well, DefaultInt), but to_i32 returns Int32, and these, again, are different types.

Next I started to try compiling and running the std specs. So far I got int_spec.cr and string_spec.cr down. But making things work is very easy! You just try compiling something and the compiler will guide you.

How to use it?

Run make clean crystal, then you can do bin/crystal spec spec/std/string_spec.cr and see it pass.

What's next?

I'll be continuing to make more and more code compile. I expect this will be a huge diff. Also, don't expect this to go out soon, or even, because it's just an experiment. And I'll do this slowly if I have time.

Rant

I wish we could push branches here. That way I could make a PR that targets that branch and the commits here will be cleaner. I see no reason why we have to restrict ourselves like that. /cc @waj @bcardiff

[waj]

@asterite feel free to push branches. I just suggested that we don't do it by default for every feature/fix branch we create for our PR's. But in specific circumstances like this one, where you might want to split the work differently or receive contributions to your branch, let's do whatever is more appropriate.

[asterite]

Closed in favor of #9619