On Tue, November 29, 2011 19:19, Thaddy wrote: > On 29-11-2011 18:49, Tomas Hajny wrote: . . > There's a documented delphi version: almost complete D7 support *by the > compiler* and by now d2006 now almost feature complete. > If you read me correct, I won't try to do any rtl related stuff. It is > sufficient to protect against obvious compiler incompatibility, macro's, > C type operators. Nothing else. Most of them are compiler switches, not > library features. Throwing a warning in these cases has real value for > me. (I am running my own rtl and libraries anyway: KOL+ system unit > replacements for fpc and delphi 3-2010). > So, no, I agree, this should not and probably can not pursue any or all > incompatibilities. > It can pursue however, to try to make life easier for people who need > both single sourced FPC and delphi code. > I do not plan to extend on $mode delphi which is documented as almost > 100% Delphi7 compatible, . .
As pointed out by others, the Delphi 7 reference doesn't imply that there are no features only available in later Delphi versions. What is "obvious" is also questionable, IMHO - I don't own/use Delphi myself, but I believe that e.g. ability of FPC to use properties outside classes is not supported in Delphi. Does that still belong to the "obvious" category from your point of view (although it is not a standalone language construct but just an extension of a construct supported in Delphi)? Again, I'm not a maintainer of the compiler code so I probably won't have to tackle the increased complexity of the compiler/parser code myself, but the ratio between benefits and costs (compiler slow-down due to many added checks not necessary for compilation plus more importantly the increased complexity of both the existing code and also maintenance of the proposed feature required in the future) seems to be fairly bad in this case... I understand that you may benefit, but I'd also say that your case is fairly specific (most FPC users use also the supplier RTL, etc.). Just my two cents (I'll try not to comment on this any further to avoid endless discussions and I won't be the one assessing any potential patch coming from your side providing implementation of that proposed feature)... Tomas _______________________________________________ fpc-devel maillist - [email protected] http://lists.freepascal.org/mailman/listinfo/fpc-devel
