This must have been asked before, but I couldn't find any details. My question is about having an untyped const param vs a normal typed param.

program Project1;{$mode objfpc}{$H+}
procedure Foo(P1: Integer; const P2); overload;
begin    writeln('const ', P1);    end;
procedure Foo(P1: Integer; P2: byte); overload;
begin    writeln('byte ', P1);    end;
var  aByte: byte;  aWord: word;  aString: string;
begin
   Foo(11, 1);         // byte
   Foo(21, aByte);      // byte
   Foo(22, aWord);      // byte
   Foo(31, aString);    // const
   readln;
end.

It looks like the compiler prefers the "P2: byte" for all signed/unsigned int types?

Or in general terms:
A typed param (to which the argument can be converted) is *always* preferred over an untyped param?

Is that something that can be trusted upon?
Is it documented somewhere (I could not find it)?

What are the values of aByte and aWord?
I would suggest testing with aWord value greater then 255.

Virgo Pärna wrote

What are the values of aByte and aWord? I would suggest testing with aWord value greater then 255.

Did some testing myself. With fpc 3.2.0 with -O- byte version is still used, if actual aWord value is greater, then maximum byte value. And that is even then, when I modified Foo to actually use P2 (added len parameter to both versions). So it cannot be any optimization, that P2 is not used. So, it looks like a compiler bug.