That would absolutely NOT break anything in FPC, in fact, it would most likely help make some of these
random bugs go away..
The compiler has a problem and there is no getting around it. You can argue the point until the cows come
home and even then, the point is still valid.
back in my college days pascal on the mainframe was one of the languages we were taught, kind of
archaic but at least is was something. Back then it was very clear how a CONSTANT is to be treated.
The argument on the left of a non constant dictates what the constant type is going to be for that case, unless
it can not be resolved then the system generates a fault at error check time.
Delphi fallows this perfectly.
Now take this example
AWordVariable := AWordVarliable+1;
Fpc handles this correctly although doing the AWordVariable+1 will result in a integer in the background but
the compiler knows that it has to demote the type to a WORD, this is done correctly, why can't it do it for
parameters ?
Now this is where it falls apart.
DOing these same steps with in a Function parameter (….) decides to not demote the type back to where it
should be but instead change it to a integer level and if you are calling system in a remote unit like the system
unit, it does not complain, just picks the wrong overload..
But if you do the math outside and the pass the results the compiler then keeps it as a WORD, that is obvious
since we showed that.
Are we starting to see the picture here?
---------------------------------------------
Another way this falls apart in your code.
Procedure Test(W:Word); overload;
Procedure Test(I:Integer);overload;
Test(SomeWord+1);
---
The last time I checked, the compiler will stop and tell you it can't figure out which one to use.
at least it knows there is a comflict, one that it is causing on its own.
Simply put, it needs to do a silent cast to prevent this and if the user decides to cast it to a higher level
then the compiler can take route since it has already promoted it in the background.