Array of Integer as parameter accepts Integers

[Fibonacci]

Seems like an Integer can be passed to a procedure that accepts an Array of Integers. Why is that?

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

1. uses SysUtils;
2.  
3. procedure test(a: array of integer);
4. var
5.   i: integer;
6. begin
7.   writeln('len  = ', length(a), ', size = ', sizeof(a):3);
8.   for i := 0 to high(a) do writeln(i, ' = ', inttohex(a[i]));
9. end;
10.  
11. begin
12.   //test(1);           // project1.lpr(14,9) Error: Incompatible type for arg no. 1: Got "ShortInt", expected "{Open} Array Of LongInt"
13.   test(integer(1));
14.   //test($ffff);       // project1.lpr(16,13) Error: Incompatible type for arg no. 1: Got "Word", expected "{Open} Array Of LongInt"
15.   test(integer($ffff));
16.   test($ffff+1);
17.   test(123456789);
18.  
19.   test([1, $ffff, $ffff+1, 123456789]);
20.  
21.   readln;
22. end.

len  = 1, size =   4
0 = 00000001
len  = 1, size =   4
0 = 0000FFFF
len  = 1, size =   4
0 = 00010000
len  = 1, size =   4
0 = 075BCD15
len  = 4, size =  16
0 = 00000001
1 = 0000FFFF
2 = 00010000
3 = 075BCD15

[MarkMLl]

Seems fairly logical to me: you've declared the parameter to accept any number of integers in an array. This might be mode-specific: what compiler mode are you using (and what compiler version etc.)?

MarkMLl

[ASerge]

Seems like an Integer can be passed to a procedure that accepts an Array of Integers. Why is that?

Yes, this is not reflected in the documentation.
For example from Delphi 7 documentation:

Within the body of a routine, open array parameters are governed by the following rules.

• They are always zero-based. The first element is 0, the second element is 1, and so forth. The standard Low and High functions return 0 and Length - 1, respectively. The SizeOf function returns the size of the actual array passed to the routine.
• They can be accessed by element only. Assignments to an entire open array parameter are not allowed.
• They can be passed to other procedures and functions only as open array parameters or untyped var parameters. They cannot be passed to SetLength.
• Instead of an array, you can pass a variable of the open array parameter's base type. It will be treated as an array of length 1.

I have bold the last point. FPC extended this action not only for variables, but also for constants, but only those for which the type is set.

[Fibonacci]

Kudos ASerge, always like your responses

[PascalDragon]

Seems like an Integer can be passed to a procedure that accepts an Array of Integers. Why is that?

Open array parameters are essentially a pointer to the first element and an additional argument with the high value of the array. It's logical that one can also pass single elements as essentially a single element array. This is compatible to Delphi and works in any mode that supports open array parameters. If it's not documented then someone please file a bug report against the documentation.

[marcov]

It is not just accepting one element, but more the omission of the [] ?

[TRon]

@marcov
exactly that.

Because if that would to be desired behaviour then why

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

1. Foo();

Is considered an error.

Should it not be considered an empty array by that same logic ?

[marcov]

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

[jamie]

Don't see a problem here?

The compiler is going to build an array for the parameter in both cases. The "[..]" only needed to not confuse the compiler between parameter count and element count entries beyond one element for the array.

I believe other languages do the same in this case that have managed arrays.

[simone]

I had already reported this behavior here:

https://forum.lazarus.freepascal.org/index.php/topic,58489.msg435598.html#msg435598

I reiterate my perplexity, given the strong typing of pascal. A scalar parameter of type integer is not an array of integers with length =1. This behavior is justified only by implementation reasons. But I know I'm in the minority..

[TRon]

@marcov:
thank you for the verifcation

@jamie:
So in your view there is not an issue with the following ?

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

1. procedure Foo(a: array of integer);
2. begin
3. end;
4.  
5. procedure Foo(a: integer);
6. begin
7. end;
8.  

I do see a problem there but perhaps that is just me ?

@simone:
you might perhaps be in the minority but I would call it an abomination 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.

[simone]

Tron, I agree. I'm glad there's at least one authoritative forum member who thinks the same way I do on this point.

[440bx]

That Foo example really shows why the compiler should _not_ accept an integer variable as a single element array.  It is ambiguous.

The compiler chooses the Foo with the integer parameter but, there is no indication of any kind that is the choice it makes.

The compiler should require the [] to eliminate the ambiguity its absence creates.  The fact that it doesn't require it should be considered a bug.


@simone,

add 1 (me) to the count of members that agree with you.

[jamie]

No, I don't see a problem with it, Compiler still generates an array which can be tested in code.

the brackets are only there to enclose multiple entries. either way, an array is created.

I'll step out the spotlight on this one because I would rather the compiler allow reduce syntax as much as possible.

[alpine]

@simone
Count me also.