[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 hav=
e 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=EBl