[fpc-pascal] Implicit conversion problem with TDate type

[Jonas Maebe]

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