[fpc-pascal] Two possible generics bugs
Sven Barth
pascaldragon at googlemail.com
Sat Nov 30 19:04:43 CET 2019
Am 29.11.2019 um 22:56 schrieb Ryan Joseph via fpc-pascal:
>
>> On Nov 29, 2019, at 2:00 AM, Sven Barth via fpc-pascal <fpc-pascal at lists.freepascal.org> wrote:
>>
>> Why? It does say that a class type is expected. And the column of the error should point to the correct location.
>> That's the same error you'd get when specializing outside of a generic with a non-class type.
> I think you're right, my fault for not looking at the column close enough.
>
>>
>>> The "specialize" is part of the generic identifier, so it must be "FGL.specialize TFPGObjectList<T>".
>>>
>>> That said however an internal error should not happen (especially the one I just added some days ago ^^'). Please report this one.
>>>
>> That doesn't look right to my eyes but ok. I filed a report (https://bugs.freepascal.org/view.php?id=36377).
>>
>> The idea is that "specialize" belongs to the identifier just like "generic" does. This comes especially apparent for nested specializations:
>>
>> SomeUnit.specialize SomeType<... >.specialize SomeFunc<... >
> What's your plan to make an implicit specialize modeswitch? I remember you said you wanted to and it sounds like low-hanging fruit I could maybe help with. The specialize keyword is a bit much in my opinion and it sounds like it could be omitted like Delphi mode does.
Well, if you want you can find any place where the _SPECIALIZE and
_GENERIC tokens are used and checked against mode Delphi to check
against a new modeswitch instead ("GENERICKEYWORDS") which must be
enabled by default in all modes except the Delphi ones.
Please note however that disabling the generic keywords also restricts
some expressions that the compiler can handle as the Delphi syntax is
not completly without ambiguity and not completly handled in the parser yet.
Regards,
Sven
More information about the fpc-pascal
mailing list