[fpc-devel] C-block reference syntax (blocker for 3.2)

[Martin Frb]

On 12/12/2019 08:51, Michael Van Canneyt wrote:
>
>
> On Wed, 11 Dec 2019, Ryan Joseph via fpc-devel wrote:
>
>>
>>
>>> On Dec 11, 2019, at 4:16 PM, Michael Van Canneyt 
>>> <michael at freepascal.org> wrote:
>>>
>>> It does gain something: it tells you it is NOT a varargs, but an 
>>> array of
>>> const, which is a different beast altogether.
>>
>> But it's a syntax equivalent for "a variable amount of arguments", 
>> i.e. varargs. ;) I guess others don't see it this way however.
>
> Somecall(fmt : String; args : Array of Const; anOptionalArg : TType = 
> SomeDefault);

That still would not break, but it actually is the base for something 
that would break.

IIRC, the request was not to always drop the [], but only if "array of 
..." was the *last* param.

In the above, it is not the last param. But if some code had been 
written years ago (and published it):
   procedure Somecall(fmt : String; args : Array of Const);

And now it was amended to
   procedure Somecall(fmt : String; args : Array of Const; opt: integer 
= 0);

Today that would work. Old code without "opt" still compiles.

But if People had used the "drop []" and written code
   SomeCall('x %d', 1,2); // meaning SomeCall('x %d', [1,2]);

That would break.
It was already mentioned, that the [] can be dropped if the array has 
*exactly one* element.

So with opt in place, and todays ruleset:
   SomeCall('x %d', 1,2); // means SomeCall('x %d', [1],2);

But that means,  if [] are allowed to be dropped at the end, and people 
had written (*before* "opt" was added)
   SomeCall('x %d', 1,2);  // meaning SomeCall('x %d', [1,2]);
then after adding "opt" it would still compile, but it would change meaning.
The "2" which would have been part of the array, would suddenly become 
"opt". (the rule allow dropping [] at the end no longer applies)