[fpc-devel] Some compiler changes...

[Daniël Mantione]

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 
   even warnings.
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 
3.

As some Delphi 8+ features break all ugliness records, expect them to
be put into categories 2,3,4.

Daniël