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
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
