I'm hitting a snag with 1.to(10): the compiler complains that it's an unresolved type. For example, try running this:
main! = |_args| {
r = 1.to(10).fold(0, |acc, item| acc + item)
echo!(r.to_str())
Ok({})
}
I get this error:
This is trying to dispatch a method named fold on an unresolved type variable, but unresolved type variables have no methods.
It has no way to know what the type is... can you add a type suffix? 1.U64.to(...
Ah, yeah it should default to Dec I guess
It has no way to know what the type is... can you add a type suffix? 1.U64.to(...
this is the thing I was talking about in #ideas
the .. syntax fixes it
Yes, I would expect it to default to Dec. Also note that 'a'.to('z') fails as well. I would expect it to assume U8.
'a' and 'z' work just like number literals; they aren't hardcoded to U8
this is in part because you can also do stuff like '😃'
which don't fit in U8
so if you did ['a', 'b', '😃'] and the small ones were hardcoded to U8, that would be a type mismatch - whereas this way it Just Works and they can work with whatever type they end up getting used as
Oh good point, thanks. So what type should the compiler default to in this case? Dec as usual? Or should it be an integer type? I can't think of a case where a character would be used to initialize a Frac.
for simplicity and flexibility it just works exactly the same way as a number literal
so writing 'A' and writing 65 do exactly the same thing
and 'A' is just syntax sugar for 65
Last updated: Jun 16 2026 at 16:19 UTC