[fpc-pascal] Feature announcement: implicit generic function specializations

[Sven Barth]

Am 22.04.2022 um 15:48 schrieb Rainer Stratmann via fpc-pascal:
> Am Mittwoch, 20. April 2022, 19:15:15 CEST schrieb Sven Barth via fpc-pascal:
>> This feature is enabled with the modeswitch
>> ImplicitFunctionSpecialization and is for now not enabled by default as
>> this has the potential to break existing code.
> How many percent of the users need this feature?

We don't deal in percentages, however it reduces the amount of typing 
required to write code with a lot of specializations (in theory an IDE 
like Lazarus *could* help here as well however).

> Is it a feature that is a must?

It's only syntactic sugar, so *normally* a feature as this wouldn't be 
really be given much of a thought, however Delphi supports it as well.

> Can everyone get also a solution without the feature?

Yes, by simply doing the specializations as usual (e.g. "specialize 
Add<String>('Hello', 'World')" instead of "Add('Hello', 'World')"). As 
said, this is pure syntactic sugar.

Please note however that sometimes we also introduce features that you 
can't workaround that will also require changes to code if that feature 
in question is used (mainly by enabling the modeswitch). The RTTI 
attributes come to mind, cause then the directive clause for function 
directives can no longer be used if you want to use them:

=== code begin ===

{$mode objfpc}
{$modeswitch prefixedattributes}

function Foobar: LongInt; [stdcall, inline]; // this part is invalid
//function Foobar: LongInt; stdcall; inline; // and needs to be written 
like this
begin
end;

begin
end.

=== code end ===

> Does it justify the risk of the whole language (has the potential to break
> existing code)?

That is why it's behind a modeswitch and not enabled by default, so that 
it's in control of the user whether they want this or not. The problem 
space is rather small, but it nevertheless exists: you need to have a 
normal routine overloaded with a generic routine (for example across 
different units) and the compiler must decide to do an implicit 
specialization instead  of using the non generic routine (as it does 
without the feature enabled / before the feature was implemented), but 
the specialization of that function then needs to fail, because the 
generic routine can't be used with the type the compiler picked

Regards,
Sven