[fpc-devel] [] property overloads

[Michael Van Canneyt]

On Tue, 2 Jul 2019, Michael Van Canneyt wrote:

>
>
> 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.

I had a quick peek in the compiler sources.

In pexpr.pas, before processing the [, the compiler calls this:

         { we need the resultdef }
         do_typecheckpass_changed(p1,nodechanged);

In my opinion, this routine will/should error out if there are 2 symbols
called 'StringArray' : one with type 'array property' and one with type 'enumerator'.

But someone of the compiler team should confirm/deny this.

Michael.