The current behavior is a wrong behavior and should be fixed.
Imagine an ancient 8 bit compiler where int was 8 bit. Then things evolved and now you have int16. Your old behavior was:
dim n as int // int8
n = 16 * 16 // should raise overflow exception?
// Your n is now zero, 256 > $FF
Then you introduced int16 and rewrote:
dim n as int16
n = 16 * 16
// Your n should be now 256
But thats NOT the issue here
The example should be
dim n as int // int8
n = 16 * 16
// Your n is now zero, 256 > $FF
And now we release a new versions and n is now 256
THAT is much more likely to cause silent errors and issues since its a behavior change
Understand I’m not saying the behavior IS (or isn’t) “correct”
It is what it is and we change things like this with a great deal of trepidation BECAUSE they can silently make significant differences in the compiled code
Let me say it in other way, respectfully: 
// In case of:
Dim n As Int64
n = 1024 * 1024 * 1024 * 20
// n MUST be 21474836480 in ANY situation, even in a context where in the past a broken compiler allowed another value
- Reread my post above yours
- Try this and tell me what you get
[code]#include
int main(int argc, const char * argv[])
{
long long number = 1024 * 1024 * 1024 * 10 ;
// insert code here...
std::cout << "Hello, World!\
" << number ;
return 0;
}
[/code]
test$ g++ test.cpp -o test.bin
test.cpp: In function int main(int, const char**):
test.cpp:6:42: warning: integer overflow in expression
This is one of those cases where you can easily be fooled by the results when you fail to consider what is happening internally. If you think this is bad try coding in PL/1 on IBM mainframes some day. One of the books for the language is about an inch thick and goes through all of the rules of what takes place internally when you mix various data types. And that language allows you to literally throw just about anything in to a mathematical equation. You learn to be very cautious and work with only the data types that are truly needed to accomplish your task. I know Norman has spoken about his past use of PL/1 so I am confident that he knows what I am talking about. It was my all time favorite programming language during my working career but you had to really pay attention to your data types in mathematical equations. I don’t consider this a bug. It is, as others have stated, a case of being sure to let the compiler know your intentions.
Its JUST a compiler warning but its JUST a warning not “this code won’t EVER compile”
Run the compiled code
C++ does the same thing and the type overflows and you get OMG the same “wrong” result despite the fact that LONG LONG is likely at least 8 bytes
So please when you say “The current behavior is a wrong behavior and should be fixed.” make sure you get the LLVM and GCC folks to also FIX their “wrong” behavior on evaluating an expression
LONG LONG is, on most platforms, at least the same size as int and more often at least 8 bytes (or 64 bits)
Then go back and reread
[quote=89300:@Norman Palardy]
Understand I’m not saying the behavior IS (or isn’t) “correct”
It is what it is and we change things like this with a great deal of trepidation BECAUSE they can silently make significant differences in the compiled code[/quote]
We don’t break code unless we HAVE to
And we REALLY try breaking it silently like this would
So while it might be nice to infer the literal type from the the of the value being assigned to it MIGHT break code in weird & surprising ways and THAT is to be avoided even more so.
I’ve already said this more than once & I’m not likely to debate this further nor reply further
Chuckling to myself reading this and thinking “OMG my book laid flat on my desk ALL the time”
The pages finally fell out of it the spine was so busted up 
No Norman. Assembly, C and C++ stands as they were meant to be. They do exactly what you say to do.
We are talking about a High Level language with roots in Basic, and I (wrongly?) assumed that it should do coercion (implicit conversions, widening) and not allowing unexpected values to pass without exceptions. I do still think it can’t allow wrong values to pass unharmed or we can’t trust in Xojo to control high precision robots with guns.
High level languages infers things to maintain the correctness of the values like http://msdn.microsoft.com/en-us/library/k1e94s7e.aspx
Same answer over & over
[quote=89316:@Norman Palardy]We don’t break code unless we HAVE to
And we REALLY try breaking it silently like this would
So while it might be nice to infer the literal type from the the of the value being assigned to it MIGHT break code in weird & surprising ways and THAT is to be avoided even more so.
[/quote]
So regardless of what you THINK might be “correct” we’re unlikely to change the behavior because it MIGHT break code in a very silent way and suddenly the program you compiled in one version still compiles fine in another but BEHAVES differently when you run it.
No warning
No error
Just different behavior
THAT is far worse
And please test very rigorously any code that controls gun-wielding robots. In fact, I suggest immediate adoption of the XRDT, the Xojo Robot Disarmament Treaty. Negotiations will convene in Zurich.
Why Zurich?