In Rebol2, R3-Alpha, and Red... division produces a DECIMAL!:
red>> 5 / 2
== 2.5
I've never been crazy about the too-easy production of of DECIMAL!s.
Red Added // for INTEGER!-Division
>> 5 // 2
== 1
That thread is very long and GitHub collapses it for some reason, be sure to click the "LOAD MORE" to see the whole thing. (Note in particular @hiiamboris's modulo tests and graphs.)
Note they might remove it. It's a long thread and hard to know what Nenad's conclusions are when he doesn't weigh in. But he did drop it from a milestone in 2022.
The big carry-away here is that this is a very nuanced topic that is tough to solve simply. Boris asks:
"Are we defining
//as a divide operation that always produces an integer (float // float = int; int // float and float // int too) or a divide operation that does not promote the operands when they are both integers (only int // int)? (what will make more sense?)"
Then there's other datatypes, VECTOR! etc...
My Leaning Is Almost Always Less Implicit Behavior
...and because I like // very much for APPLY, I'm happy to use DIV instead for infix integer division with no remainder.
>> 5 / 2
** Error: INTEGER! division not even, use DIV or cast to DECIMAL
>> 5 div 2
== 2
>> (to decimal! 5) / 2
== 2.5
With FENCE! running CONSTRUCT, I've proposed what construct does is that if the first expression resolves to a DATATYPE!...it interpret it as an intent to create that type.
This gives a lighter syntax:
>> (to decimal! 5) / 2
== 2.5
>> {decimal! 5} / 2 ; saves 3 characters, but drops an entire word
== 2.5
I'm Okay With INTEGER! / INTEGER! Giving An Error If The Result Isn't An INTEGER!
A lot of times when I divide things that are integers I know they are evenly divisible.
If I don't know they are, then a decimal dropping out rarely "just works" without some additional code or mitigation, unless I'm printing out some kind of percentage result and the usage stops at the user's eyes.