Array of Integer as parameter accepts Integers

[VisualLab]

@simone:
...as the example clearly shows that you can't rely on the behaviour because as soon as you overload your code behaves differently (and without any warning or indication). imho useless and dangerous behaviour.

I agree. I also think this should be fixed.

[jamie]

Creating another incompatibility to Delphi?
 

[TRon]

Creating another incompatibility to Delphi?
 

I am all fine and dandy with Delphi compatibility...

Delphi Seattle refuses the example code with "constants cannot be used as open array arguments".  For all four of the ones without [].

But please let someone be precise which version of Delphi that should be because that is the one question in over two decades that nobody was able to answer and seem to shift all over the place. The compiler compatibility being one and something as simple as the RTL being another one of them. Shouldn't be a difficult question to answer because Delphi users should be able to run into these incompatibility issues all the time. If not for the one version of Delphi then for the other (because Delphi ain't even compatible with itself over all these years). Once you get into the nitty gritty details then this becomes a serious problem and is one of the reasons that Delphi compatibility means bupkis anymore to me these days.

mode delphi does not make ones code Delphi compatible.

[ASerge]

Code: Pascal  [Select][+][-]

1. {$APPTYPE CONSOLE}
2.  
3. procedure Proc(const A: array of Integer); overload;
4. begin
5.   Writeln('Proc with array');
6. end;
7.  
8. procedure Proc(const A: Int64); overload;
9. begin
10.   Writeln('Proc with single');
11. end;
12.  
13. var
14.   i: Integer = 1;
15. begin
16.   Proc(i);
17.   Readln;
18. end.

This code outputs "Proc with single" in FPC 64x, but is rejected by the compiler in 32x Delphi7: [Error] Project1.dpr(16): Ambiguous overloaded call to 'Proc'.
Please, test on FPC 32x.

[simone]

Recently I'm a bit surprised when a compiler behavior is justified by the need to maintain compatibility with Delphi. This argument is important in principle, but since I realized that core developers and most of the community are against the acceptance of the most recent features introduced by Delphi (such as the infamous inline variables), then I realized that by now the roads have divided and therefore compatibility is a less and less requested need.

[440bx]

it's noticeable that compatibility with Delphi isn't a consistent requirement.  Sometimes it is, sometimes it isn't.


@Serge,

I'm pleased you tested that in Delphi.  The ambiguity is obvious and allowing it is an obvious bug (apparently incompatible with Delphi)

[Thaddy]

Please, test on FPC 32x.

There is not a point in testing it if integer in Delphi has a different meaning.
It is only testable if the fpc compiler mode is also specified. The default mode is fpc mode and the size of an integer = smallint.
https://www.freepascal.org/docs-html/current/ref/refsu4.html#x26-250003.1.1
In DCC32 and DCC64 XE2 and dcc32/d12 the output is Proc with array, in D7 it does not compile at all and in fpc 3.3.1 in delphi mode the output is as you described,  "Proc with single", which seems wrong indeed.
Seems two bugs: one in Delphi7 since the code should compile as in XE2 or higher, and one in fpc where the evaluation order/precedence seems wrong.

[PascalDragon]

it's noticeable that compatibility with Delphi isn't a consistent requirement.  Sometimes it is, sometimes it isn't.

The point of Delphi compatibility is that Delphi code compiles in FPC with mode Delphi, but NOT that code written in FPC's Delphi mode compiles in Delphi.

(Inline variables - which would be required for Delphi compatiblity - are a special topic, because the majority of the core devs - me included - is against this feature as whole)

[Thaddy]

Delphi compatibility is walking through murky waters anyway as my tests showed.