[fpc-devel] Some compiler changes...
daniel.mantione at freepascal.org
Tue Jan 23 15:33:42 CET 2007
Op Tue, 23 Jan 2007, schreef Bram Kuijvenhoven:
> Well, if for Chrome and/or Delphi support we need the &, then it will have to
> be implemented anyway.
Only if we are able to compile code we currently cannot compile. For
Chrome it would be a long term project before you can compile anything,
since any Chrome code uses .NET libraries. Further, FPC code won't
import types or extent objects from other .NET languages, as it is
not a .NET compiler. There is nothing bad about being Chrome compatible,
but one has to argue how realistic it is.
For Delphi, most Delphi code bases are Win32 and don't use .NET language
features. If that changes, the urgence for FPC to have D8+ features
increases. Until now, D7 as limit has been a good choice.
> But whether one wants to use it, might simply be a
> matter of taste.
There are many disgusting language features in Delphi. There are several
ways of dealing with those:
1) Support them fully in all modes.
2) Support them only in Delphi mode.
3) Support them in Delphi mode, but remove the fun by printing hints or
4) Not supporting them.
The decision depends on a case by case basis. Code exchange between Delphi
and Objfpc modes should for example be possible without rewriting the
code. So even while a feature is a bit ugly, it can get into category 1.
However, a feature that is just a type saver could go into category 2, and
if it endangers type-safety or code correctness, it can go into category
As some Delphi 8+ features break all ugliness records, expect them to
be put into categories 2,3,4.
More information about the fpc-devel