chr is just a way to transform an int value to a char without performing any type checks. You can think of it as a cast in C. We could maybe have another method to raise if the integer isn't a valid char.

I think I'd prefer chr to do the check and have unsafe_chr or so. Or perhaps we can even just allow .to_u32.as(Char)?

The check will just be checking that the integer is in 0..Int32::MAX, right?

I did a couple of benchmarks, in non-release mode it's twice as slow, but in release mode there's no difference. I guess then it's worth improving this.

The benchmark I did is:

require "benchmark"

struct Int
  def chr!
    unless 0 <= self <= Int32::MAX
      raise ArgumentError.new("#{self} out of char range")
    end
    chr
  end
end

a = 0
Benchmark.ips do |x|
  x.report("chr") do
    "foo bar".each_byte do |byte|
      a += byte.chr.ord
    end
  end
  x.report("chr!") do
    "foo bar".each_byte do |byte|
      a += byte.chr!.ord
    end
  end
end
puts a

Of course we'd rename chr to unsafe_chr, and chr! to chr (should be very easy not that we define primitives in Crystal code 😸)

Hmm... actually, the name is still hardcoded in the compiler:

You're by now more of a UTF-8 expert than me by now, but it looks like 0x10ffff? My goal would be that if foo.chr does not raise, so it'll be impossible for foo.chr.bytesize and foo.chr.each_byte to raise.

Mmm... on second though, never mind. We can add an "unsafe_chr" there too, and in codegen too. The @[Primitive] think is just so that we can add docs to it, but the primtiive names still need to be hardcoded.

Right, 0x10ffff should be the maximum value, I don't know why I put Int32::MAX there. I re-ran the benchmark, numbers are the same.

Do you want to send a PR for this? We'd need to check Crystal::VERSION to define chr or unsafe_chr in primitives. In main visitor we can check for both names (the chr condition will be never met in 0.18.0, later we can remove it). And I think chr can be added to Int, no need to add it to each specific integer.

Otherwise I can do it too :-)

Please do, you have a better grasp of which chrs in the stdlib would need to change to unsafe_chrs, if any.

Oh and perhaps we should extract 0x10ffff as Char::MAX...