Specialisation doesn't seem to always create a new type

[nixbody]

The FPC documentation states that: "Whenever a generic class is specialized, this results in a new, distinct type." (please see https://www.freepascal.org/docs-html/ref/refse57.html). But that doesn't seem to be the case for every specialisation. In a unit specialisations of one generic type with the same type parameter seem to share one generated type.

Code: Pascal  [Select][+][-]

1. {$MODE OBJFPC}{$H+}
2.  
3. type
4.   generic TTest<T> = record
5.   end;
6.  
7. begin
8.   WriteLn(IntPtr(TypeInfo(specialize TTest<Integer>)));
9.   WriteLn(IntPtr(TypeInfo(specialize TTest<Integer>))); // Same address.
10. end.

Do I misunderstand the documentation and this is supposed behaviour or is it a bug (either in the documentation or in FPC)?

Thank you for your kind answers.

[Zoran]

If it behaves so, then I'd say it is a bug -- it doesn't behave as documented.

Please report. Let the fpc developers decide whether documentation or implementation should be changed.

[PascalDragon]

The FPC documentation states that: "Whenever a generic class is specialized, this results in a new, distinct type." (please see https://www.freepascal.org/docs-html/ref/refse57.html). But that doesn't seem to be the case for every specialisation. In a unit specialisations of one generic type with the same type parameter seem to share one generated type.

What the documentation should mean is that each specialization with different types for the parameters results in a distinct type. For the same types it's an implementation detail whether they are the same or not and this may change with future versions or the optimizations used.

[nixbody]

Ok, thank you for clarification. I should have known better that these things are usually implementation details. From the language of the documentation it seemed that I can rely on every specialisation to produce a new type which would be awesome for my use case, but it is what it is and I get it. Should I report it then? I mean the documentation.

[PascalDragon]

Should I report it than? I mean the documentation.

Yes, please report it (for the documentation subproject). You can quote my post for a potential improvement of the documentation.

[korba812]

Maybe a type alias would be helpful in your use case?

Code: Pascal  [Select][+][-]

1.     {$MODE OBJFPC}{$H+}
2.      
3.     type
4.       generic TTest<T> = record
5.       end;
6.       MyInteger = type Integer;
7.  
8.     begin
9.       WriteLn(IntPtr(TypeInfo(specialize TTest<Integer>)));
10.       WriteLn(IntPtr(TypeInfo(specialize TTest<MyInteger>))); // Different address.
11.     end.

[nixbody]

Thank you for your suggestion, I thought of that. I could also provide a second value parameter (I'm using trunk), but that's all pretty error-prone and clunky for the user (programmer) who would need to always define a new type or make sure that second parameter is a unique value for the type. What I'm trying to achieve is an emulation of local thread variables in routines (static thread_local in C).