[fpc-devel] New feature announcement: constant parameters for generics

[Benito van der Zander]

Hi,

>
>
> Also assume you have a record and a hashmap that stores them. Now you 
> add a string to the record which turns it into a managed one and 
> suddenly your code will no longer work, probably resulting in subtle 
> bugs or memory leaks. That's /not/ what should happen for merely 
> adding a string. It's already bad enough that this happens with the 
> Pascal style I/O we don't need to have this with base container types.
>
> For calling Free we have explicit classes. But the difference between 
> managed types vs. not-managed types is subtle and can change - as 
> mentioned above - by merely adding a field.

That is why FreePascal should merge non-managed generic classes that 
have the same size when it can.

But as long as FreePascal does not do it, the user needs to do the 
merging manually, with all the resulting problems. And constants 
generics can be used to store the size

Best,
Benito
On 27.04.20 07:46, Sven Barth wrote:
> Am 26.04.2020 um 23:42 schrieb Benito van der Zander:
>> Hi Sven,
>>
>>>
>>> It's not that simple. In principle you're right that the compiler 
>>> could try to merge more implementations, but this does not depend on 
>>> the declaration of the generic, but the use of the parameter types.
>>
>> I mostly use generics for containers, especially hashmaps. They only 
>> stores the values and never calls specific methods on them
>>
>
> Well, nice and well for /you/ then, but there are many more uses for 
> generics. And as a compiler developer I /must/ think about these cases 
> as well.
>
>>>
>>>
>>> Not to mention that your TBaseHashMap would not work with managed 
>>> types...
>>
>> That would need be handled separately. There are probably also people 
>> who want a container that calls .free on TObject descendants.
>
> The user should not need to care about that, especially for general 
> base classes.
>
> Also assume you have a record and a hashmap that stores them. Now you 
> add a string to the record which turns it into a managed one and 
> suddenly your code will no longer work, probably resulting in subtle 
> bugs or memory leaks. That's /not/ what should happen for merely 
> adding a string. It's already bad enough that this happens with the 
> Pascal style I/O we don't need to have this with base container types.
>
> For calling Free we have explicit classes. But the difference between 
> managed types vs. not-managed types is subtle and can change - as 
> mentioned above - by merely adding a field.
>
> Regards,
> Sven
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20200428/f2bcb7c4/attachment.html>