cc @isuffix who had opened #5969

I'm wondering whether we actually want to keep this behavior. Perhaps, we should rather turn this into a hard error and require the dot to explicitly turn it into a float.

Actually, I also find the behaviour weird. There should be a warning at least, like the warning for decimal(1.0).

• If the typst code is generated by some program, then it's more appropriate to generate json/cbor/... and use data loading functions.
• If the typst code is written by hand… Oh I can't image how can that be. @kokic, do you have a real use case?
• Nevertheless, the v0.13.1 behaviour can be retained by #let n = yaml(bytes("9223372036854775808")).

Apologies for the regression! I should've checked the behavior in ast.rs more carefully.

However, I do agree with Laurenz that this is weird. I would consider it an odd piece of trivia if #type(1000000000000000000) differed from #type(10000000000000000000) (there's an extra zero). I don't think erroring on a too-large integer (with hints to either add a dot or use bytes) would be an undue burden.

Another option discussed in #5462 is to just warn on this case, but I don't think changing the type to a float ever really makes sense, so I would prefer an error and require an explicit dot.

Separately, we should just add methods int.min() and int.max() (or maybe int.MIN?) to help with the negative minimum use-case.

Given the precedent of float.nan, I think it would just be int.min. Uppercase is not really a thing in Typst (which is sometimes annoying because it means variables unnecessarily collide with types ...)

Let's turn it into a hard error.

Actually, let's first merge the fix and then introduce the hard error in a separate PR. That way I could cherry-pick should we decide to cut a point release.

Thanks! Feel free to open a second PR for introducing a hard error. :)