[fpc-devel] potential bug, generics vs helpers

[Kornel Kisielewicz]

On Fri, Jan 27, 2012 at 6:37 PM, Sven Barth <pascaldragon at googlemail.com> wrote:
> Am 27.01.2012 17:46, schrieb Thaddy:
>> On 27-1-2012 17:25, Marco van de Voort wrote:
>>> In our previous episode, Kornel Kisielewicz said:
(snip)
> ===
>
> This compiles!
>
> So there MUST be specific code in place in the Delphi compiler to allow the
> assignment from ugendiamond2.TSpez2 to ugendiamond1.TSpez1 as those are
> different definitions. Thus this can not be a bug, but must be an
> intentional feature. Allowing this in FPC as well would be doable.
>
> Now regarding Kornel's problem: we could(!) change the way the compiler
> works in non-Delphi modes to what is described in the documentation (by
> adding the type symbol's name to the generic's name as well), but this will
> mean that we would have to define how units in Delphi and non-Delphi modes
> can interact here. After that the corresponding code in the compiler can be
> implemented to ensure this.

What I still don't understand is the way the code is compiled in the
diamond case. Let's assume that TGeneric in this example has a lot of
code. So after compilation we have:

ugendiamonddecl.ppu
ugendiamond1.ppu
ugendiamond2.ppu
ugendiamonddecl.o
ugendiamond1.o
ugendiamond2.o

As you stated, the ugendiamonddecl.ppu holds the tokens for generation
of TGeneric, so the code is "kept" in ugendiamonddecl.ppu. What about
the object files? The only reasonable general solution I see is that
both ugendiamond1.o and ugendiamond2.o hold the generated code --
Delphi may do it otherwise because it may use different intermediate
file formats (true?)

In this case FPC's specialize could be the mode to be "smarter"
requiring a explicit instantiation that at the same time shows in
which object should the code be stored.

It's kind of like the problem with the instantiation and template
export in C++...

Also, I'd be a big fan of extending the FPC version of templates in
the direction allowing more powerful generic metaprogramming (without
the broken C++ heritage), and I think that explicit instantiation
would simplify that quite a lot.
-- 
regards,
Kornel Kisielewicz