ParamArray or ParamArray()

I’ve always create methods with ParamArrays like this:

Sub SubName (ParamArray v As Integer)

This works except the IDE doesn’t recognize that v is an array for the purposes of auto-complete. I used this form because I thought it was required, but today I’ve discovered that this works too:

Sub SubName (ParamArray v() As Integer)

This seems to do exactly the same thing except that auto-complete works. I thought that the second form would have expected a series of integer arrays instead of integers as parameters, but no.

So is there a functional difference between the forms? And is there a way to pass a series of arrays instead of integers (or strings, or whatever)?

I think you found a bug

Which form do you think is the bug?

It makes no sense to support forms…

I think the bug is:
ParamArray v() As Integer

and Autocomplete not recognizing the other forms parameter as an array

Xojo does not support an array of arrays without using variants and that is what this form implies… So bug

[quote=18072:@Karen Atkocius]I think the bug is:
ParamArray v() As Integer[/quote]

the other way around :wink:
See: <https://xojo.com/issue/18367>

From Joe Ranieri: [quote] This is actually the intended syntax for ParamArray, with the non-array syntax being a bug that has been preserved for backwards compatibility.[/quote]

Interesting. So there is no way to construct a ParamArray of arrays, so I couldn’t create a method that accepted this:

MyMethod( array1, array2, … )

this should be possible with a function defined to accept a ParamArray myArrays() as Variant
But you will have to test for IsArray and ArrayElementType for each element of myArrays at runtime…

Right, but you lose the compiler’s type checking. That method could be called, without compiler complaint, as:

MyIntArrayFunction( intArray, dictArr, aDict, aDouble, … )

An imperfect solution.

I think joe mentioned on another post somewhere that

myfunction( paramarray v() as integer )

is the one syntax that was supposed to work but a bug in the implementation also meant

myfunction( paramarray v as integer )

worked - but was not supposed to - and they behave the same. In the code called v is an array of integers.

There is no way to specify an “array of arrays” anywhere in the language (and multi dimensional arrays aren’t arrays of arrays)

It has always been documented (and still is) the other way. Nowhere have I ever seen the form

myfunction( paramarray v() as integer )

in the documentation. It’s always been

myfunction( paramarray v as integer )

This “bug” is a little more pervasive than you seem to be indicating.

The “bug” is that both work and both mean the same thing
But fixing that would break a pile of code

[quote=18984:@Tim Hare]It has always been documented (and still is) the other way. Nowhere have I ever seen the form

myfunction( paramarray v() as integer )

in the documentation. It’s always been

myfunction( paramarray v as integer )

[/quote]

I did read the docs when paramarray was first introduced and it was documented as myfunction( paramarray v as integer ). I had never seen the other form and as I said it seems to me the other form is a bug because it implies an array of arrays,

It could also be said that there is a documentation bug in that as @Tim Hare said, it the instances of ParamArray documentation show it as ParamArray a As Integer, not the proper ParamArray a() As Integer. So, the docs are promoting further incorrect usage, or exploitation of this bug, and to the detriment of the user as code completion does not work on the buggy way of defining a ParamArray.

IIRC in REALStudio code completion did recognize the parameter as an array using ParamArray a As Integer.

At this point, the two should be considered synonymous and any original design goals or bugs are historical footnotes.

So the bug is that with the syntax

paramarray v as string

Autocomplete treats v as a simple string, not an array. Ie., typing “v.u” will autocomplete v.Uppercase instead of v.Ubound.

Note that “v(1).u” autocompletes correctly as v(1).Uppercase.

[quote=19041:@Tim Hare]So the bug is that with the syntax

paramarray v as string

Autocomplete treats v as a simple string, not an array. Ie., typing “v.u” will autocomplete v.Uppercase instead of v.Ubound.

Note that “v(1).u” autocompletes correctly as v(1).Uppercase.[/quote]

Thankfully there’s a whole category in Feedback for autocomplete bugs.