[fpc-devel] potential bug, generics vs helpers

[Sven Barth]

On 28.01.2012 00:16, Kornel Kisielewicz wrote:
> On Fri, Jan 27, 2012 at 10:25 PM, Sven Barth
> <pascaldragon at googlemail.com>  wrote:
>> On 27.01.2012 19:05, Kornel Kisielewicz wrote:
>>> 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.
>>
>> No. A definition should be stored where it is defined. I can't just use
>> ugendiamond1 for storage, because then ugendiamond2 will depend on
>> ugendiamond1 which might not be the intention. Also what about units that
>> were definitely compiled by different people, but by "accident" have the
>> same specializations? You can't store them in the ugendiamonddecl.ppu/.o
>> either, because that file must be considered fix.
>
> What I meant was a solution (only for FPC mode) that only allowed
> compatibility between specializations.
>
> So if ugen1 and ugen2 would both have specialization TGeneric<>  then
> the situation would be as now (two instances), only no assignment
> would be possible. To have a possible assignment you'd have to have
> them both include a common unit that has this particual
> specialization. Basically restricting template assignment only to the
> same instantiation as stated in the manual, which would allow to
> choose between one or several instantiations.

I believe that having an overview over which types are assignable to 
which other types in a bigger application will be rather difficult.

> However, this suggestion is void, due to the Matrix/Vector case I
> mentioned before.

Maybe it's definitely better if we go the Delphi route even if we won't 
be able to define helpers for two "different" specializations using the 
same type...

>>> 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.
>>
>> The only thing I would add to FPC generics that's a bit in the direction of
>> C++ templates (besides constraints which are also a Delphi feature and thus
>> need to be supported sooner or later) would be the ability to "specialize" a
>> generic with constants (and that only if I have too much time and no other
>> feature to attend to).
>
> I actually faked a small part of that in one of my programs by using SizeOf ;).
>
> type GNumeric1 = byte;
> type GNumeric2 = packed array[2] of byte;
> type GNumeric3 = packed array[3] of byte;
> ...
>
> // and use the "constant":
>
> generic GenericArray<T,Size>  = record
>    Data : array[0..SizeOf(Size)-1] of T;
> end;
>
> type IntArraySize2 = specialize GenericArray<Integer, GNumeric2>;
>
> Booleans can be similary faked.

A have to admit, that is neat O.o

>
>> But that's it! No more C++ template ways.
>
>> I don't
>> want a turing complete compile time construct in FPC!
>
> I guess it's too late :P.
>
> Let's start with something simple...
>
> generic GNumericInc<N>  = packed record
>    unused1 : Byte;
>    unused2 : N;
> end;
>
> generic GNumericAdd<N>  = packed record
>    unused1 : Size;
>    unused2 : Size;
> end;
>
> generic GNumericSquare<N>  = packed record
>    unused : array[0..SizeOf(Size)-1] of Size;
> end;
>
> generic GNumericMult<A,B>  = packed record
>    unused : array[0..SizeOf(A)-1] of B;
> end;
>
> However, I have yet to find a way to stop a recursive loop :P (yes,
> I've got a Boost background)

Somehow I fail to see what you exactly want to show me here. Would you 
please explain?

> On a more serious note however, we don't want a C++ templates-like
> monster, however any enhancement that allows more powerful
> compile-time code generation that is clean and doesn't affect normal
> code isn't something to ditch. Although I'd need to seriously rethink
> that, to come up with something powerful, yet clean and simple enough
> not to provoke code bloat and exponential explosion of compile time.

The biggest problems are:
* backwards compatibility (I did quite some thinking around many corners 
to implement Delphi compatible generics in a way that allowed old 
non-Delphi-mode generics to still be compileable as is)
* Delphi compatibility (regarding new features at least so far that 
generics can still be used in a Delphi compatible way)
* not too much complication of the parser (it already got a bit more 
complicate by me implementing support for "mylist := 
TFPGList<LongInt>.Create" and I don't have yet implemented generic 
functions which will allow things like this in the end: "if 
myfunc1<LongInt>(42) < myfunc2<LongInt>(21) then ..." [I hope you can 
spot where the parser will have problems ^^])

Regards,
Sven