[fpc-devel] Implicit function specialization precedence

[Sven Barth]

Am 06.04.2021 um 17:45 schrieb Ryan Joseph via fpc-devel:
> Finally some movement is happening on implicit function specialization and I'm almost finished now except some questions about precedence have been raised again. Initially I thought we decided on non-generic functions taking precedence in the case of *any* name collisions (the original thread https://lists.freepascal.org/pipermail/fpc-pascal/2018-December/055225.html) but Sven is saying now that this isn't the case (see the remarks on the bug report https://bugs.freepascal.org/view.php?id=35261). I'm asking this here not to go over Svens head but in hopes to get some answers quicker (it can take us weeks sometimes to round trip even simple questions).
>
> Currently what I implemented is that in the case below non-generic Test() will take precedence even though Test<T> could be specialized and indeed even comes after.  My questions:
>
> 1) What is required for Delphi compatibility? I never used Delphi and I thought we decided this initially for Delphi compatibility. Of course we can make a Delphi mode only option if we need to.
>
> 2) Svens final remarks on the bug tracker are "Right now your code will pick the existing String overload even if specializing the generic might be the better choice. If the user really wants the String one (or if the specializing the generic does not work) the user can still force the String overload by casting the parameter to a String.". I'm confused about this because Test(String) and Test<String> are both identical and thus I don't see what is the "better choice".
>
> Personally I feel like we should fallback to the non-generic function as a way to resolve ambiguity but I can also see why Test<T> should take precedence simply because it comes after Test().

In the example you posted below, I agree with you, but that is not what 
I said. Look at my example again:

=== code begin ===

program timplicitspez;

{$mode objfpc}{$H+}
{$modeswitch IMPLICITFUNCTIONSPECIALIZATION}

function Test(const aStr: String): LongInt;
begin
   Result := 1;
end;

generic function Test<T>(aT: T): LongInt;
begin
   Result := 2;
end;

operator := (aArg: LongInt): String;
begin
   { potentially expensive conversion }
   Result := '';
end;

begin
   Writeln(Test('Hello World'));
   Writeln(Test(42));
end.

=== code end ===

The important part here is the operator overload. If the generic 
function would not exist then the compiler would simply call the 
operator overload to convert the 42 to a String and call the function 
with the string overload. While in this example the conversion is 
essential a no-op in reality it might be more complex and expensive thus 
it might be better to use the implicit specialization of the 42 as is 
(in this case it would be a LongInt I think). Right now there is no 
possibility to enforce the use of the implicit specialization.

In this specific case the two functions also are *not* ambigous, because 
for the non-generic Test the parameter requires an implicit conversion, 
but the implicit specialization does not. For example if there would be 
a "Test(aArg: LongInt)" instead of the generic the compiler would pick 
that instead of the string one. So if you move the check for generic vs. 
non-generic to the end of is_better_candidate all the other rules to 
determine this will take precedence.

And to pick the non-generic one can do this in the above example: 
Test(String(42)), because here the type your implicit specialization 
code will receive will be String already and thus the generic vs. 
non-generic check will catch it and prefer the non-generic one.

Also Delphi agrees with me:

=== code begin ===

program timplspez;

{$APPTYPE CONSOLE}

uses
   SysUtils;

type
   TFoo = record
     f: LongInt;
     class operator Implicit(aArg: LongInt): TFoo;
   end;

   TTest = record
     class function Test(aArg: TFoo): LongInt; overload; static;
     class function Test<T>(aArg: T): LongInt; overload; static;
   end;

class operator TFoo.Implicit(aArg: LongInt): TFoo;
begin
   Result.f := aArg;
end;

class function TTest.Test(aArg: TFoo): LongInt;
begin
   Result := 1;
end;

class function TTest.Test<T>(aArg: T): LongInt;
begin
   Result := 2;
end;

var
   f: TFoo;
begin
   f := 21;
   Writeln(TTest.Test(f));
   Writeln(TTest.Test(42));
   Writeln(TTest.Test(TFoo(42)));
   Readln;
end.

=== code end ===

=== output begin ===

1
2
1

=== output end ===

This should answer both your points, cause they're related.

Regards,
Sven
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20210406/f07ef514/attachment.htm>