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@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
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
