Decimal to Integer assignment warning

[ernestasjuska]

Hi,

Today, I was reminded that where is no compile time check when assigning from decimal to integer type. The error only appears at runtime.

Please add warning when assigning decimal expression to integer without using Round(Number, Precission[, Direction]) with second parameter being integer expression. IMHO, if some custom function is doing the rounding and returns decimal it is still programmers responsibility to make sure the rounding result is actually an integer.

Actually, it is more complex than that. You could in theory do IntegerVar := Round(3.14) * 100, or IntegerVar := 0.5 * 2 or even IntegerVar := Round(3.14) * Round(HundredsWithFraction, 1). Not sure if this should be allowed (almost certainly not - too complex analyzer for too little added value).

Thanks.

P.S.: I have a question for the god - WHY? 😄

[Arthurvdv]

I spent some time looking into the AL compiler internals to better understand what's actually feasible here, and I wanted to share what I found and would love to hear what everyone thinks.

What I found

In the literal case:

MyInteger := 3.14;

the compiler silently folds 3.14 to 3 (truncation) without producing a warning, while the runtime throws the overflow you encountered. So there does seem to be a genuine gap here. The challenge is deciding how broad a rule should be.

The design trade-off

• Constant-only (narrow but precise): Only flag assignments where the right-hand side is a compile-time constant decimal with a fractional part (for example, := 3.14 or := 10/3). This would avoid false positives entirely, but it might only catch a relatively small number of real-world cases.

• Type-based "possible overflow" (broader): Flag any decimal-typed expression that's assigned to an integer. This would catch more potential issues, but it would also warn on code that's perfectly valid. For example:

  MyInteger := Round(Customer.Balance, GetRoundingPrecision(), '=');

  Here the runtime value is an integer, so the code is correct. One workaround Iknow of is forcing an integer result with div 1 (for example, MyInteger := 3.14 div 1). However, applying that idea more generally would mean recommending something like:

  MyInteger := Round(...) div 1;

  which doesn't feel like a great solution. It becomes even less meaningful when GetRoundingPrecision() itself could return 1.

The core challenge is that correctness often depends on the runtime value, and that's something a static analyzer can't know. So there's a real trade-off between catching more issues and avoiding unnecessary warnings. To me, there isn't an obvious "right" answer, which is why I'd like to hear the community's perspective before we decide whether (and how) to implement this rule.

I'd love to hear your thoughts

I'm curious how this shows up in real-world code, so if you've come across something similar, I'd really appreciate hearing about it.

Whether you've run into this yourself, have an opinion on what a rule should (or shouldn't) flag, or can think of examples that illustrate the trade-offs, please share them. I'm especially interested in cases where the "right" behavior isn't obvious.

Some things that might be useful to hear about are:

• Situations where an assignment from Decimal to Integer caused unexpected behavior.
• Examples where a warning would have been genuinely helpful (and where it would just have created false positives).
• Patterns or coding styles that you think should always be flagged, or should never be flagged.
• Any other edge cases or scenarios that come to mind.

The more real-world examples we can collect here, the easier it will be to judge whether a rule makes sense at all, and if it does, where the right balance between accuracy and usefulness lies.

Any feedback or real-world examples would be greatly appreciated.

[ernestasjuska]

Yes, this is very niche rule and, personally, I only encountered this once in recent time. Still, with AI coding taking off, I wonder...

XML file export report used export quantities and amounts as integers, but then the required format changed and it had to export fractions (e.g 1234 g old format -> 1.234 kg in new format). So I converted all numbers from integers to decimals, corrected roundings, tested what happens with fractions and I was done.
But this code had to also be backported to old NAV and this task was given to our junior programmers. They also did pretty much all and missed some procedure parameters that also had to change from integer to decimal. Were it to lack of testing or whatever, but that code ended up in production. Of course, it was old NAV and there is no code analysis there, but still such error can be made.

My problem is that compiler does not complain, and it is kind of understandable why, but still there is a reliable way to check this at compile time with only few false positives.

Examples of the top of my head:

1. Dialog - @1@@@@@@@@ placeholder takes integer, naively doing ProgressDialog.Update(1, ProcessedCount * 10000 / TotalCount)) will show error. This does not really require code analysis, since this error will almost certainly be caught during testing.
2. Adding milliseconds to DateTime or assigning milliceconds to Duration will show error if milliseconds is not whole number.
3. Reading integer looking number from JSON that can sometimes be a decimal and assigning it to integer (wrong target type).
4. Calling function that takes integer with decimal expression by mistake - NAV error screenshot from production in my suggestion.

I know that div 1 acts like Round(..., 1, '<') for positive values. Either, if such rule was implemented it should use actual types. Assigning constant will not happen - and if it were to happen it would be caught during testing (though reality could hit us with a brick like this: if RareCondition then IntegerVar := <decimal-expression> else IntegerVar := <integer-expression>;).

Thanks.