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.
_______________________________________________
fpc-devel maillist - [email protected]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
