- Is there a issue for this so I can follow up? (I can not find any issues for such topic)
No.
- Will it be fixed with the implicit generic specialization Ryan and you are working on? (I am following the issue and development)
At least for those cases for which the implicit specialization would indeed work, yes. (Side note: in case of an implicit specialization the
specialize keyword also isn't required in non-Delphi modes, in fact it's not even allowed, because
specialize and
<…> belong together)
It would however not work if you use types, cause those don't take part in implicit specialization (adjusted example from above):
program tgenfunc;
{$ifdef USE_MODE_DELPHI}
{$mode delphi}
{$else}
{$mode objfpc}
{$endif}
type
{$ifndef USE_MODE_DELPHI}generic{$endif} TTest<T> = class
class function GetValue(aArg: T): T;
end;
class function TTest{$ifdef USE_MODE_DELPHI}<T>{$endif}.GetValue(aArg: T): T;
begin
Result := aArg;
end;
var
a: LongInt;
begin
a := {$ifndef USE_MODE_DELPHI}specialize{$endif} TTest<LongInt>.GetValue(42) +
{$ifndef USE_MODE_DELPHI}specialize{$endif} TTest<LongInt>.GetValue(21);
end.
This will lead to similar errors as in the original example when compiled with
USE_MODE_DELPHI defined.
- Is there or will there be a compiler option to use the Delphi mode generic with FPC mode without leaving the FPC mode?
There is not, but I have it on my todo list to introduce such a modeswitch. But this is
very low priority and needs some other things working first. Please note that the same restrictions as in mode Delphi would apply then, cause it's not the mode per-se that's the cause for these restrictions, but the presence or absence of the
specialize keyword which makes things easier for the parser.
- Can I ask what is your idea about what is the better option in the long run? The Delphi generic mode or the FPC one?
I personally favor the non-Delphi mode generics.