[fpc-devel] [] property overloads

[Michael Van Canneyt]

On Tue, 2 Jul 2019, Ondrej Pokorny wrote:

> On 01.07.2019 23:25, Michael Van Canneyt wrote:
>> I understand. But all depends on how the compiler parses and evaluates 
>> this.
>>
>> Let me put brackets to make it more clear: is
>>
>> MyTest.StringArray[i]
>>
>> parsed & evaluated as
>>
>> (MyTest.StringArray)([(i)])
>>
>> or as
>>
>> (MyTest.StringArray[(i)])
>>
>> In the former case, the compiler cannot know what the result type is 
>> of the
>> first set of brackets in your proposal. In the latter case, it can be OK.
>>
>> But I simply do not know, someone with more intimate knowledge of the
>> compiler needs to shed light on this.
>
> I happened to study this part of FPC code back in 2015 when I worked on 
> issue #28820. I can say that FPC directly transfers indexed properties

Stop... How does FPC decide it is an indexed property ?

Because 'directly  transfers indexed properties ' implies the compiler
*already decided* that it is an indexed property and needs to convert to
calls.

> to method calls with the parameters from []-brackets without checking if 
> the property definition exists - and even without checking if the 
> []-brackets are there.

If so, and I have no reason not to believe you, that is very worrying :-)

> ---
>
> So actually, what you call as "my proposal" is not really a proposal - 
> the whole property overload feature is already present in FPC. But now 
> it's just by accident and with wrong syntax. We only need 2 steps to 
> convert this bug into a feature:
> 1.) Check the indexed property definition before calling the 
> getter/setter + allow indexed property overloads.
> 2.) Forbid the empty-[]-brackets-syntax so that "c.Index[]" and 
> "c.Index[][2]" from example above will become invalid.

You could very well be right.

Can someone of the compiler team please comment ?

Michael.