Hi List.

I think i have found a bug related to enumerators, overridden methods and forward declared classes.

Please consider the code listed here:
http://pastebin.com/8EkVDG5n

The problem seem to be that the a descendant enumerator class overriding a virtual method cannot
return a class which i only forward declared.

If the TFoo and TBar classes are moved above the TBarListEnumerator the code compiles without
any problem.

Should I add this to the bugtracker?

Regards
Torsten Bonde Christiansen.

ps. my compiler details:

ppcx64 -i
Free Pascal Compiler version 2.6.4

Compiler Date : 2014/03/12
Compiler CPU Target: x86_64

Hi List.

I think i have found a bug related to enumerators, overridden methods and forward declared classes.

Please consider the code listed here:
http://pastebin.com/8EkVDG5n

The problem seem to be that the a descendant enumerator class overriding a virtual method cannot
return a class which i only forward declared.

If the TFoo and TBar classes are moved above the TBarListEnumerator the code compiles without
any problem.

Should I add this to the bugtracker?

Regards
Torsten Bonde Christiansen.

ps. my compiler details:

ppcx64 -i
Free Pascal Compiler version 2.6.4

Compiler Date : 2014/03/12
Compiler CPU Target: x86_64

In our previous episode, Torsten Bonde Christiansen said:

Yes. The code with Tfoo and TBar above also shouldn't not compile, at least not in Delphi mode.

Marco van de Voort wrote

Yes. The code with Tfoo and TBar above also shouldn't not compile, at least not in Delphi mode.

The double negative is intended here?

Bart

In our previous episode, Bart said:

> Yes. The code with Tfoo and TBar above also shouldn't not compile, at least > not in Delphi mode. The double negative is intended here?

No. So Delphi refuses when TFoo and TBar are declared at the top. IMHO rightfully so.

Both Delphi and FPC also refuse the alternate forward declaration with inhertiance ( TBar=Class(TFoo); ), that would at least declare before use of the relation. I don't know what the motivation is for refusing that.

What you do this for? Using override directive makes no sense in this case, so I suggest you just don't use it. If you don't use it, the descendant enumerator will still work like intended

22.03.2014, 20:21, "Torsten Bonde Christiansen" :

What you do this for? Using override directive makes no sense in this case, so I suggest you just don't use it. If you don't use it, the descendant enumerator will still work like intended

I Think override makes perfect sense in this case.

I get to only implement the GetCurrent procedure once, the example is simplified but in my real-world application it does some additional structure checking, and in all derived classes i get to call the ancestor method but return an object of the type i need.

If I could not override the code for GetCurrent the following

forBar inBarList do
     Bar.Val2:=1;

would not be able to know the Bar is a TBar, but would rather see Bar as a pointer (since in this case it inherits from TList). And all subsequent code would have to do some sort of typecasting.

I hope that makes a little bit of sense...

Regards,
Torsten.

Should I report this as a bug where this construct is not allow at all (not just Delphi mode, bot all mode) or as a bug in regards to Delphi mode.

Actually i would like to see this work, at least for objfpc, also with the construct where forward declared classes is possible.

Regards,
Torsten.

In our previous episode, Torsten Bonde Christiansen said:

Report it as a bug that it is not allowed at all in the current situation, with the added note that Delphi doesn't allow it either.

Actually i would like to see this work, at least for objfpc, also with the construct where forward declared classes is possible.

That's a separate language enhancement request, read http://www.freepascal.org/faq.var#extensionselect

Since this is already possible in objfpc mode (at least partially) is it nessesary to mark
it as a bug? I think of this as an undocumentet feature, which perhaps just needs
testcases to ensure reliability.

If you still consider it a bug I will spend some time trying to write a proposal as stated in
the link you send previously.

Regards,
Torsten.

In our previous episode, Torsten Bonde Christiansen said:

Yes. A case where a check is missing doesn't automatically mean a feature has been implemented where that check is not needed.

Overriding methods with declarations that don't match the original is a big thing.

Crap... this means I have to redo some of my code. ;)

-Torsten.