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

Reply via email to