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

Hairy Pixels genericptr at gmail.com
Sat Apr 30 13:17:25 CEST 2022

> On Apr 25, 2022, at 8:27 PM, Hairy Pixels <genericptr at gmail.com> wrote:
>> For some reason I don't get all mails by Ryan, so I reply here:
>> Helpers currently can't be generic and even if they could be (which I do plan to add) it would require an explicit specialization of the helper to be used because the compiler will not be tasked with searching for potential generic helpers and then implicitly specializing a whole helper type with all its methods to maybe use it for an implicit specialization (and it needs to specialize the helper first to decide whether it even remotely contains suitable methods). 
> You could do a search for method names and parameters to see if a generic helper was a candidate before specialization. That would reduce the possible space for needless specializations right? For non-object types this would be even less intrusive since it would only be competing with other helper methods.

Note: CC’ing Sven in case he’s not getting these.

First off see my reply above about implicit. Question is why can’t you filter out possible helpers by doing a pre-pass check for matching names? It’s certainly going to add some compile time overhead but it can be put behind a mode switch in the case it’s worthwhile (the compile time may be negligible in many cases). There’s also some optimizations I could think of so I wouldn’t give up on implicit specialization  just yet.

I had a look at some old notes I had on the idea of generic helpers since we talked about this some years back (for generic arrays) and here's what I found.

2) Right now helpers only support single types but they would need to be extended to support “array of T”, “set of T”,which by, why aren’t those supported as it is? I can’t seem to think of any reason they should be disallowed. The alternative is using an auxiliary generic type which kind of confounds things because then you’re extending a new type instead of the underlying array of set type.

3) If there was a generic helper for a generic class it may be too verbose to use the normal inline specialization syntax ie:

	generic THelper<T> = class helper for specialize TMyClass<T>

So I wonder if the shorthand:

	generic THelper<T> = class helper for TMyClass

Could be used, providing the type to be extended has a matching generic parameter list. At the very least the “specialize” sounds wrong when reading it.

	Ryan Joseph

More information about the fpc-pascal mailing list