On 02/11/16 12:09, Tony Whyman wrote:
It's an interesting concept i.e. if a bug exists in Delphi then it must
also exist in FPC. Perhaps a better alternative is to fix these sort of
bugs in FPC and to introduce a "full Dephi compatibility mode" i.e.
mode Delphi plus the bugs.
There is a difference between having a code construct that can be
compiled in one mode and not in another, and code that has different
behaviour in different modes. The former can be easily recognised, the
latter is much harder. In particular, it complicates reading code,
because you constantly have to be aware of the mode to know what the
code means. The same goes for changing behaviour across compiler
versions, and we have to do this way more often than I like.
Both of those things are symptoms of the worst possible situation you
can have in terms of code readability, while it is supposed to be one of
the focus points of Pascal.
We already have a few cases of code that compiles both in FPC and in
Delphi mode, such as this:
function func: longint;
begin
func:=1;
if func<>2 then
writeln('ok');
end;
In FPC mode this writes 'ok'. In Delphi mode this causes endless
recursion. These are the worst kinds of gotchas, and most of them were
introduced in the early days of FPC when we indeed thought we would fix
everything that is wrong with TP. In the end, in many cases we just
introduced our own set of idiosyncrasies that you have to know about to
avoid getting bitten.
As Lacak mentioned, you can change the behaviour of this particular case
yourself if you want, without having to go over all existing code
written in FPC/ObjFPC mode to ensure that none of it relies on the
existing behaviour (assuming that this would be changed by adding the
extra operator Laco mentioned in a unit that would only be included in
programs compiled in FPC/ObjFPC mode).
Jonas
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
